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Abstract 


The  ubiquity  of  mobile  wireless  devices  greatly  magnifies  the  threats  of 
clandestine  physical  tracking,  profiling,  and  surveillance.  This  is  because 
these  devices  often  reveal  their  identities  and  locations  to  third  parties,  either 
inadvertently  to  eavesdroppers  nearby  or  in  reports  to  location-based  services. 

In  this  dissertation,  we  address  the  challenges  in  building  practical  wire¬ 
less  protocols  and  services  that  protect  users  from  these  threats.  To  under¬ 
stand  the  nature  of  the  problem,  we  first  quantify  how  easily  eavesdroppers 
can  track  devices  that  use  802.11,  the  dominant  local  area  wireless  protocol 
for  the  foreseeable  future.  Using  wireless  traffic  from  hundreds  of  real  de¬ 
vices,  we  show  that  eavesdroppers  can  track  802. 1 1  devices  accurately  even 
if  explicit  identifiers,  such  as  MAC  addresses,  are  changed  over  time.  This  is 
because  implicit  identifiers,  or  identifying  characteristics  of  802.1 1  traffic,  can 
still  identify  many  users  with  high  accuracy.  We  develop  an  automated  proce¬ 
dure  that  can  identify  users  even  when  countermeasures,  such  as  pseudonyms 
and  encryption,  are  employed. 

In  response  to  these  shortcomings,  we  present  the  design  and  evaluation  of 
an  802.1 1-like  wireless  link  layer  protocol  that  obfuscates  all  transmitted  bits, 
rather  than  select  fields,  to  increase  privacy.  By  obscuring  all  bits,  we  greatly 
increase  the  difficulty  of  identifying  or  profiling  users  from  their  transmis¬ 
sions.  Our  design,  called  SlyFi,  is  nearly  as  efficient  as  existing  schemes  for 
discovery,  link  setup,  and  data  delivery  because  transmission  requires  only 
symmetric  key  encryption  and  reception  requires  a  table  lookup  followed  by 
symmetric  key  decryption.  Experiments  using  our  implementation  on  Atheros 
802. 1 1  drivers  show  that  SlyFi  performs  comparably  with  802. 1 1  using  WPA. 

Finally,  we  demonstrate  how  to  build  wireless  service  directories  that  can 
not  track  users  who  submit  location-aware  reports.  This  problem  is  increas¬ 
ingly  relevant  for  802. 1 1  hotspot  directories,  which  may  rely  on  users  that  sub¬ 
mit  accurate  information  about  hotspot  location  and  characteristics  but  want 
to  remain  anonymous.  We  present  Wifi-Reports,  a  location-based  service  that 
provides  Wi-Fi  clients  with  historical  information  about  AP  location,  perfor¬ 
mance,  and  application  support.  Wifi-Reports  addresses  two  conflicting  goals: 
preserving  the  privacy  of  users’  reports  and  limiting  fraudulent  reports. 

Our  contributions  demonstrate  that  future  wireless  protocols  and  services 
need  not  sacrifice  users’  privacy  in  order  to  be  practical. 
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Chapter  1 
Introduction 


Privacy  is  widely  recognized  as  one  of  the  most  important  unresolved  issues  associated 
with  information  technologies.  For  example,  a  recent  CRA  report  identified  “security  that 
users  can  understand  and  privacy  that  they  can  control”  as  a  grand  challenge  for  Trustwor¬ 
thy  Computing  [44].  Similarly,  the  Federal  Trade  Commission  identified  privacy  as  cen¬ 
tral  to  its  consumer  protection  mission  in  light  of  modem  computer  and  communications 
technologies  [54].  Meanwhile,  significant  public  outcry  has  followed  privacy  incidents 
involving  network  devices  and  services  (e.g.,  AOLs  release  of  poorly  anonymized  Web 
search  queries  [15],  Intel’s  introduction  of  Processor  Serial  Numbers  [6],  and  Benetton’s 
addition  of  RFID  into  their  clothing  [26]). 

In  the  context  of  network  architecture,  the  protection  of  information  privacy  [164]  has 
primarily  been  achieved  by  maintaining  the  confidentiality  of  messages.  That  is,  no  en¬ 
tity  other  than  the  sender  or  intended  recipient  can  access  the  contents  of  a  message  and 
the  sensitive  information  therein.  Much  effort  has  concentrated  on  developing  end-to-end 
and  link-layer  protocols  that  encrypt  messages  to  provide  this  form  of  privacy  (along  with 
other  security  properties).  The  result  has  been  many  techniques  that  make  the  recovery  of 
the  contents  of  encrypted  messages  computationally  infeasible,  even  under  strong  assump¬ 
tions,  such  as  an  attacker  with  prior  knowledge  of  the  encryption  algorithm.  On  the  whole, 
these  techniques  have  been  extremely  successful  (despite  occasional  problems  [30,  34]) 
and  protocols  that  use  these  techniques,  such  as  IPSEC,  SSL,  and  WPA,  are  now  in  com¬ 
mon  use. 

However,  the  emergence  of  ubiquitous  computing  devices  raises  new  privacy  concerns 
not  addressed  by  these  techniques.  A  sample  of  these  devices  includes  headsets,  game 
controllers,  mobile  phones,  laptops,  cameras,  audio  and  video  players,  and  specialized  de¬ 
vices  such  as  blood  pressure  monitors  with  wireless  communications.  These  devices  are 
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networked  and  are  rapidly  becoming  integral  parts  of  our  daily  lives  —  people,  cars,  and 
homes  may  now  have  many  of  these  devices  to  provide  rich  and  seamless  network  con¬ 
nectivity.  Unfortunately,  three  properties  of  this  class  of  devices  raise  additional  threats: 

Mobility  of  Devices.  Unlike  desktop  computers,  which  served  as  the  primary  interfaces 
for  network  access  during  most  of  the  previous  30  years,  these  devices  are  often  carried 
with  their  users  as  they  go  about  their  daily  lives.  Moreover,  many,  such  as  smart  phones 
and  wireless  sensors,  are  used  to  connect  to  the  Internet  and  to  each  other  in  an  oppor¬ 
tunistic  manner,  often  without  requiring  user  input.  This  mode  of  network  access  implies 
that  devices  that  identify  themselves  to  third  parties  during  communication  enable  those 
parties  to  track  them  as  they  move  from  place  to  place,  even  if  the  remainder  of  their 
communication  is  encrypted. 

Wireless  Communication.  These  devices  typically  connect  to  the  Internet  and  to  each 
other  via  a  wide  range  of  wireless  links,  such  as  Bluetooth,  802.11,  WiMAX,  Zigbee  and 
GSM/UMTS.  Wireless  links  are  more  exposed  than  their  wired  counterparts  because  trans¬ 
missions  are  broadcast  and  can  be  received  by  anyone  within  radio  range  (e.g.,  about  250 
meters  with  standard  802.11b  radios  [104]).  Without  sophisticated  wiretapping  hardware 
or  access  to  network  cables,  third  parties  that  are  not  intended  recipients  may  eavesdrop 
on  conversations  using  only  commodity  radios  and  off-the-shelf  software.  For  example, 
any  nearby  observer  can  intercept  unique  low-level  identifiers  that  are  always  sent  unen¬ 
crypted,  such  as  Bluetooth  and  802.1 1  device  addresses.  Therefore,  third  entity  eavesdrop¬ 
pers  can  easily  detect  the  presence  of  their  devices  and  follow  them  from  place  to  place. 
Several  tracking  networks  for  Bluetooth  and  802.11  have  already  been  deployed  in  the 
wild  [33,  102,  103]. 

Location-based  Services.  The  mobility  of  networked  devices  has  also  given  rise  to  a  large 
number  of  location-based  services  to  which  users  may  explicitly  report  their  locations  in 
order  to  obtain  local  information.  For  example,  the  iPhone  and  Android  smart  phones  may 
send  a  user’s  location  to  Google  to  obtain  driving  directions;  a  number  of  smart  phone 
applications  report  users’  current  locations  in  order  to  retrieve  information  about  nearby 
restaurants  and  other  physical  establishments.  These  services,  therefore,  also  have  the 
ability  to  physically  track  clients  that  use  them. 

These  three  properties  significantly  magnify  the  threats  of  clandestine  physical  track¬ 
ing  and  profiling  because  they  give  a  number  of  entities  the  ability  to  collect  information 
that  ties  a  person  to  his  or  her  past  and  current  locations.  Therefore,  our  use  of  ubiquitous 
computing  devices  poses  threats  to  our  location  privacy  even  if  the  confidentiality  of  mes¬ 
sages  is  maintained.  A  growing  body  of  legal  and  social  analyses  argue  that  these  threats 
are  significant,  as  location  privacy  (as  a  form  of  contextual  integrity)  is  an  important  foun- 
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dation  for  freedom,  human  relationships,  and  liberal  democracy  [123].  The  erosion  of 
location  privacy  has,  thus,  drawn  the  concern  of  the  popular  media  [29,  168],  the  United 
States  government  [109,  169],  and  technical  standards  bodies  [81].  To  protect  location 
privacy,  users  must  be  able  to  control  when  and  with  whom  their  location  information  is 
shared. 


1.1  Location  Privacy  Threats 

The  primary  threat  to  location  privacy  comes  from  the  collection  of  location  traces.  A  lo¬ 
cation  trace  is  a  set  of  location  samples  known  to  be  from  the  same  device  or  user.  In  addi¬ 
tion  to  revealing  where  a  user  has  been,  researchers  have  shown  that  outdoor  location  traces 
(e.g.,  from  GPS  samples)  can  be  used  to  infer  a  person’s  mode  of  transportation  [130]  and 
predict  where  they  will  drive  [59,  98,  99].  Indoor  location  traces  can  be  used  to  infer  group 
gatherings  [120],  and  character  traits  [112]  (e.g.,  age,  work  role,  smoker,  coffee  drinker). 

In  order  to  collect  a  location  trace  about  a  device,  an  entity  needs  only  the  ability  to 
record  the  device’s  location  and  the  ability  to  assign  a  consistent  identity  to  the  location 
measurements  that  distinguishes  them  from  those  recorded  for  other  devices.  The  precise 
definitions  of  location  and  identity  will  shape  the  nature  of  location  privacy  threats.  In  this 
dissertation  we  typically  define  a  location  to  be  a  spatial  point  measured  with  an  accuracy 
of  100  to  250  feet  (the  local  area  wireless  transmission  range).  Knowledge  of  such  a 
location  is  usually  sufficient  to  answer  questions  about  whether  a  person  visited  a  physical 
establishment  (e.g.,  “Was  Alice  at  Bob’s  house,”  “Was  Alice  at  the  clinic,”  and  “Was 
Alice  at  the  4th  floor  office?”).  Since  we  are  primarily  concerned  with  location  traces,  we 
define  identity  to  be  any  identifier,  with  respect  to  a  set  of  location  measurements,  that  is 
consistent  and  distinguishing  over  time.  For  example,  the  MAC  address  of  wireless  traffic 
collected  at  a  location  is  an  identity  because  it  does  not  change  over  time  and  is  globally 
unique. 

It  is  important  to  note  that  the  ability  to  capture  location  traces  is  concerning  even 
if  these  identities  are  not  explicitly  tied  to  user  identities  (e.g.,  a  person’s  name).  This 
is  because  a  small  amount  of  location  context  can  be  used  to  implicitly  connect  device 
identifiers  to  user  identities  [27,  62,  64,  74,  75,  97].  For  example,  the  identity  of  a  device 
used  in  a  user’s  home  can  be  inferred  to  be  tied  to  a  person  that  lives  there.  Thus,  device 
tracking  effectively  enables  user  tracking.  Even  if  a  device  can  not  be  tied  to  a  unique 
individual,  the  ability  to  track  it  still  poses  threats.  For  example,  a  thief  might  want  to 
track  all  the  devices  that  have  been  to  a  high-end  retail  store,  regardless  of  the  identity  of 
their  owners. 
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Figure  1.1:  Entities  that  ean  deteet  the  loeation  and  identity  of  Aliee’s  deviees  (bold). 

1.1.1  A  Taxonomy  of  Location  Privacy  Threats 

The  three  properties  of  ubiquitous  eomputing  deviees  we  diseussed  above  imply  that  there 
are  a  number  of  entities  that  may  eolleet  loeation  traees  about  us.  In  this  seetion,  we 
deseribe  the  types  of  entities  that  can  obtain  both  location  and  identity  information,  how 
they  can  do  so,  and  whether  they  pose  significant  location  privacy  threats.  We  illustrate 
this  taxonomy  of  entities  by  considering  an  example  involving  a  user  Alice  and  her  devices 
(Figure  1.1). 

Internet  Service  Providers.  When  Alice  wants  to  connect  her  laptop  the  Internet,  the 
laptop  must  rendezvous  with  a  wireless  access  point  nearby,  such  as  a  Wi-Fi  access  point 
(AP)  or  GSM  base  station.  This  access  point  may  be  controlled  by  an  individual  (e.g.,  the 
Wi-Fi  AP  in  Alice’s  home)  or  by  an  access  network  Internet  Service  Provider  (ISP)  (e.g., 
the  Wi-Fi  APs  on  a  campus  network).  Since  local  area  wireless  communications  have  a 
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range  of  only  tens  of  meters,  a  Wi-Fi  AP  can  infer  that  Alice’s  laptop  is  nearby,  thereby 
learning  its  rough  location.  Since  Alice’s  laptop  typically  must  authenticate  itself  to  access 
points  before  obtaining  connectivity,  it  also  learns  her  identity.  Access  network  ISPs,  thus, 
have  the  ability  to  collect  location  traces  of  their  users.  The  scope  of  these  traces  will,  of 
course,  be  limited  to  where  ISPs  have  access  points  and  when  users  connect. 

Location  information  and  identity  may  also  be  transmitted  as  part  of  Alice’s  com¬ 
munications  subsequent  to  obtaining  connectivity.  However,  end-to-end  encryption  that 
protects  the  confidentiality  of  messages  can  prevent  ISPs  from  observing  this  information. 
Moreover,  as  we  describe  in  the  next  section,  economic  incentives  and  legal  deterrents  of¬ 
ten  exist  that  are  sufficient  to  prevent  ISPs  from  revealing  our  location  traces  under  normal 
circumstances,  so  technical  countermeasures  may  not  be  necessary. 

Ad-hoc  devices.  Alice’s  laptop  may  also  communicate  locally  with  other  wireless  devices 
such  as  her  PDA  without  going  through  an  access  network,  or  to  a  private  access  point  that 
itself  is  mobile  [133].  We  call  this  ad-hoc  communication.  Ad-hoc  communication  is  typ¬ 
ically  used  between  Bluetooth  devices  and  between  some  Wi-Fi  devices.  These  devices 
can  obviously  detect  that  Alice’s  laptop  is  nearby  due  to  the  limited  range  of  local  area 
wireless  connectivity.  However,  Alice  will  probably  only  authorize  this  communication  if 
she  owns  all  such  devices  or  trusts  their  owners.  Moreover,  the  scope  of  traces  collected  by 
ad-hoc  devices  are  limited  to  when  and  where  such  devices  communicate.  Ad-hoc  com¬ 
munication  is  typically  only  used  in  social  settings  (e.g.,  to  exchange  music  files  or  play 
games)  where  device  owners  already  have  established  social  trust  relationships.  Therefore, 
technical  countermeasures  may  not  be  necessary  to  prevent  ad-hoc  devices  from  collecting 
and  abusing  location  traces. 

Location-based  services.  Once  a  connection  is  established,  Alice’s  laptop  will  likely 
communicate  with  services  on  the  Internet.  These  services  can  obtain  the  location  of  Al¬ 
ice’s  laptop  in  a  number  of  ways:  the  IP  address  that  the  access  ISP  assigns  to  it  may  reveal 
coarse  geographic  location  (typically  to  within  10s  of  kilometers  [92])  or  the  client  may 
explicitly  measure  its  own  location  (e.g.,  using  GPS)  and  send  it  to  the  service  as  part  of 
a  query.  The  later  is  typically  the  case  with  location-based  services  (LBSes),  such  as  a 
service  that  tells  Alice  the  restaurants  that  are  nearby.  If  Alice  identifies  herself  to  these 
services  before  using  them  (e.g.,  by  logging  in),  they  then  also  obtain  her  identity.  There¬ 
fore,  services  that  record  these  two  pieces  of  information  also  have  the  ability  to  collect 
location  traces  on  their  users.  The  scope  of  these  traces  may  not  be  limited  to  a  small 
number  of  locations  because  clients  may  use  these  services  wherever  they  have  network 
access.  However,  an  LBS  can  only  collect  a  location  sample  when  a  user  makes  a  query 
to  the  service  and  they  can  not  ensure  that  all  locations  in  queries  are  actually  visited  by 
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users.  Nonetheless,  as  we  describe  in  the  next  section,  a  class  of  LBSes  that  are  also  rec- 
ommender  systems  may  need  to  collect  location  samples  more  frequently  and  accurately 
in  order  to  be  effective.  Therefore,  technical  countermeasures  to  protect  location  traces  in 
these  systems  may  be  needed. 

Wireless  eavesdroppers.  Independent  of  whether  her  devices  communicate  through  an 
access  point  or  in  an  ad-hoc  fashion  with  each  other,  eavesdroppers  nearby  can  overhear 
her  devices’  transmissions  with  proper  radio  equipment.  These  eavesdroppers,  like  access 
points  and  ad-hoc  devices,  can  infer  location  due  to  the  limited  range  of  wireless  transmis¬ 
sions.  Furthermore,  eavesdroppers  can  record  device  identities  because  they  can  observe 
low-level  identifiers  such  as  addresses  and  network  names  in  transmissions. 

For  example,  it  is  trivial  to  track  an  802. 1 1  device  today  since  each  device  advertises 
a  globally  unique  and  persistent  MAC  address  with  every  frame  that  it  transmits.  More 
generally,  802.11  facilitates  user  tracking  and  inventorying  attacks  that  are  conceptually 
identical  to  RFID  threats  [88],  which  have  prompted  much  public  concern  over  privacy. 
The  low  cost  of  802. 1 1  and  Bluetooth  hardware  and  ease  of  access  to  network  monitoring 
software — all  that  is  required  for  someone  to  locate  others  nearby  and  eavesdrop  on  their 
traffic — enable  anyone  to  track  users,  from  government  surveillance  networks  to  ad  hoc 
scanners  set  up  by  thieves  and  curious  individuals  (e.g.,  [33,  102,  103]).  Although  the 
scope  of  location  traces  collected  by  these  entities  is  limited  to  the  locations  where  they 
have  monitors  deployed,  clients  may  be  secretly  tracked  whenever  they  use  a  wireless 
device  if  a  monitor  is  nearby.  Finally,  we  note  that  the  collection  of  location  traces  by 
eavesdroppers  need  not  be  for  malicious  purposes.  For  example,  it  is  often  necessary  to 
collect  wireless  traces  for  diagnostic  purposes.  Such  traces  can  effectively  be  combined 
to  form  location  traces  because  device  identities  are  exposed.  Since  eavesdroppers  may 
have  economic  incentives  to  collect  location  traces  (e.g.,  to  profile  users),  we  argue  that 
technical  countermeasures  are  needed  to  prevent  eavesdroppers  from  collecting  them. 


1.1.2  Legal  and  Economic  Deterrents 

ISPs  typically  do  not  need  to  collect  location  traces  on  their  users  in  order  to  operate. 
Since  users  enter  into  service  level  agreements  with  network  providers  and  services  that 
they  use,  ISPs  and  LBSes  have  a  strong  incentive  to  protect  their  customer’s  privacy,  lest 
their  customers  switch  to  a  competing  ISP  that  protects  user  privacy  better.  Moreover, 
government  actors  are  prevented  from  arbitrarily  procuring  this  data  by  law  the  United 
States  [118,  157]  and  by  the  constitution  of  many  European  countries.  In  addition,  tight 
regulation  of  licensed  spectrum  used  by  cellular  networks  has  made  it  difficult  for  entities 
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other  than  ISPs  to  obtain  the  eavesdropping  equipment  for  cellular  protocols  such  as  GSM. 

Most  LBSes  only  answer  location-aware  queries  submitted  by  users  (e.g.,  “Find  the 
restaurants  near  this  location”),  and,  thus,  do  not  have  an  explicit  need  to  record  user 
identities  and  locations.  We  call  any  service  that  accepts  location-based  queries  a  query- 
only  LBS.  Since  users  explicitly  decide  to  report  their  locations  to  an  LBS,  they  can  control 
when  they  allow  these  services  to  see  their  locations  and  can  control  the  accuracy  of  the 
location  reported.  As  with  ISP  location  traces,  location  privacy  threats  can  be  further 
mitigated  if  location  traces  are  anonymized  or  obfuscated  (Section  1.3  surveys  techniques). 

Limitations  of  legal  and  economic  deterrents.  Unfortunately,  due  to  the  unlicensed  na¬ 
ture  of  the  802.11  and  Bluetooth  radio  spectrum,  existing  legal  deterrents  against  mobile 
phone  tracking  may  not  apply  to  the  tracking  of  these  devices.  Even  if  this  were  not  the 
case,  it  would  be  very  difficult  to  enforce  anti-eavesdropping  measures  because  passive 
eavesdropping  is  not  easily  detectable.  No  specialized  hardware  is  needed  to  eavesdrop  on 
802.1 1  or  Bluetooth,  so  it  is  also  impractical  to  regulate  the  sale  of  such  devices.  Further¬ 
more,  eavesdroppers  do  not  enter  into  any  contractual  agreements  with  those  that  they  are 
eavesdropping  on,  so  they  do  not  have  any  explicit  legal  incentive  to  protect  users’  privacy. 
Indeed,  the  purpose  of  eavesdropping  is  to  collect  information  about  users’  traffic,  so  they 
have  a  disincentive  to  delete  or  anonymize  location  traces. 

In  addition,  while  ISPs  have  incentives  to  protect  the  privacy  of  their  own  customers’ 
privacy,  their  wireless  networks  may  also  act  as  large  scale  eavesdropping  networks  that 
spy  on  the  communications  of  other  ISPs’  customers.  Unfortunately,  an  ISP  may  not 
be  substantially  deterred  from  protecting  the  privacy  of  these  users,  since  they  have  no 
contractual  agreement  with  them  and,  indeed,  may  find  it  useful  to  collect  location  traces 
about  them  to  profile  competitors  and  develop  ways  to  try  to  attract  their  customers.  We 
categorize  ISPs  that  behave  in  this  manner  as  eavesdroppers. 

Some  LBSes  are  Web  2.0  services  that  use  “crowd-sourcing”  (e.g.,  reports  submitted 
by  users)  in  order  to  populate  their  database.  We  term  such  LBSes  crowd-sourced  LBSes 
because  they  are  typically  used  to  recommend  services  to  their  users.  For  example,  there 
are  hundreds  of  Wi-Fi  services  providers  in  major  metropolitan  areas,  so  AP  directories, 
such  as  JiWire  [85],  Hotspotr  [78],  and  WiGLE  [167],  are  often  used  to  locate  Wi-Fi  ser¬ 
vice.  Some  of  these  directories  rely  on  crowd-sourcing  to  populate  them  because  manually 
cataloging  hotspots  across  many  geographic  areas  is  too  burdensome.  Because  reports  on 
wireless  APs  also  implicitly  reveal  locations  that  users  have  been,  these  directories  effec¬ 
tively  collect  location  traces.  These  LBSes  can  not  easily  discard  or  anonymize  location 
traces  that  they  collect  because  they  rely  on  their  users  for  location-aware  information. 

Unlike  LBSes  that  just  answer  location-based  queries,  these  LBSes  need  to  hold  users 
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entity  type 

where 

when 

non-technical 

deterrents 

access  network  ISPs 

access  point  locations 

user  uses  ISP 

legal,  economic 

ad-hoc  devices 

rendezvous  locations 

devices  communicate 

social 

query-only  LBSes 

anywhere 

user  makes  query 

economic 

crowd-sourced  LBSes 

anywhere 

user  records  report 

none 

wireless  eavesdroppers 

monitor  locations 

user  uses  wireless 

none 

Table  1.1:  Summary  of  entities  that  pose  location  privacy  threats,  where  and  when  they  can 
track  devices,  and  whether  there  are  substantial  non-technical  deterrents  against  location 
trace  collection. 

accountable  (i.e.,  by  recording  their  identity)  and  record  locations  of  their  reports  in  order 
to  provide  good  service.  Standard  techniques  to  anonymize  or  obfuscate  reports  would 
severely  degrade  the  utility  of  an  AP  directory  service,  for  example,  because  it  would 
be  hard  to  distinguish  fraudulent  and  inaccurate  reports.  Therefore,  crowd-soured  LBSes 
actually  have  an  incentive  to  collect  identifiable  and  accurate  location  traces  in  order  to 
improve  their  service.  Indeed,  these  LBSes  are  most  useful  when  its  users  submit  reports 
frequently  (e.g.,  for  every  Wi-Fi  AP  that  they  visit). 


1.1.3  Desirable  Technical  Countermeasures 

Table  1.1  summaries  the  entities  that  pose  potential  threats  to  location  privacy  and  their 
properties.  This  dissertation  focuses  on  technical  countermeasures  to  those  threats  that 
are  currently  not  substantially  mitigated  by  legal,  economic,  and  social  deterrents,  namely, 
those  posed  by  wireless  eavesdroppers  and  by  crowd-sourced  LBSes.  Technical  counter¬ 
measures  for  other  types  of  entities,  such  as  query-only  LBSes,  may  also  be  desired  in 
some  circumstances,  but  there  is  already  a  relatively  complete  body  of  work  that  addresses 
these  measures.  We  describe  this  work  in  the  Section  1.3. 


1.2  Thesis  and  Approach 

The  very  use  of  wireless  networks  by  mobile  wireless  devices  poses  risks  to  location  pri¬ 
vacy  even  if  users  trust  ISPs  that  they  connect  to  and  we  disregard  LBSes  that  are  not 
needed  for  network  communication.  In  this  dissertation,  we  seek  to  mitigate  these  loca¬ 
tion  privacy  threats  by  improving  the  mechanisms  necessary  for  network  communication 
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by  ubiquitous  computing  devices.  We  make  the  following  thesis: 


Existing  protocols  and  techniques  that  wireless  devices  use  to  discover  and 
communicate  with  each  other  pose  risks  to  users  ’  location  privacy.  It  is,  how¬ 
ever,  possible  to  redesign  these  protocols  and  techniques  to  substantially  mit¬ 
igate  location  privacy  threats  without  degrading  their  functionality  or  practi¬ 
cality. 

That  is,  we  show  that  adversaries  need  only  expend  a  small  amount  of  resources  and  ef¬ 
fort  in  order  to  track  and  profile  devices  that  use  existing  wireless  protocols.  For  example, 
eavesdroppers  can  track  and  profile  users  with  commodity  hardware  and  typical  LBSes 
can  track  all  users  that  login  and  submit  information.  The  ease  and  limited  cost  of  these 
tracking  and  profiling  attacks  imply  that  almost  anyone  with  the  motivation  can  threaten 
our  location  privacy.  The  goal  of  this  dissertation  is  to  develop  protocols  that  significantly 
raise  the  bar  for  adversaries  that  wish  to  carry  out  these  attacks  so  that  only  a  small  minor¬ 
ity  of  entities  can  carry  them  out  in  practice.  In  developing  these  protocols,  however,  we 
also  want  to  maintain  the  same  functions  of  and  achieve  comparable  efficiency  to  existing 
protocols,  so  that  adopters  of  these  protocols  do  not  have  to  make  difficult  trade-offs. 

In  order  to  illustrate  problems  with  and  solutions  for  wireless  protocols  in  general,  this 
dissertation  uses  Wi-Fi  (or  802.11)  as  a  concrete  case  study.  We  use  the  terms  Wi-Fi  and 
802. 1 1  interchangeably.  802. 1 1  is  the  most  widely  used  local  area  wireless  protocol  today, 
is  used  for  both  infrastructure  and  ad  hoc  networks,  and  is  deployed  in  devices  ranging 
from  laptops  to  cell  phones.  We  examine  empirical  802.11  networks  and  traffic  to  quan¬ 
tify  location  privacy  threats  and  develop  solutions  that  maintain  the  same  functionality  of 
existing  802.1 1  devices  and  networks.  However,  the  qualitative  conclusions  we  draw  apply 
to  the  broader  class  of  wireless  protocols,  networks,  and  services  that  we  have  discussed 
in  this  chapter. 

Users  of  802.11  devices  typically  take  the  following  steps  in  order  to  communicate 
with  each  other  and  the  Internet.  First,  when  connecting  to  the  Internet,  users  must  select 
APs  to  use.  Second,  whether  connecting  to  the  Internet  or  to  a  nearby  ad-hoc  device, 
users’  devices  rendezvous  with  relevant  APs  and  devices  (i.e.,  discover  and  authenticate 
those  nearby).  Finally,  users’  devices  communicate  data  to  APs  and  to  each  other.  Through 
their  communication,  user  devices  may  report  about  local  services  and  their  environment 
(e.g.,  about  the  quality  of  the  AP  they  are  using). 

Select.  Locating  and  selecting  an  appropriate  AP  to  use  is  an  important  part  of  the  802. 1 1 
usage  model.  This  is  typically  achieved  via  out-of-band  means,  such  as  by  matching  the 
AP’s  network  name  to  a  trusted  entity  (e.g.,  a  known  home  network).  To  facilitate  AP 
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discovery  in  unknown  locations,  a  number  of  hotspot  directories  exist  that  report  their 
locations  (e.g.,  [85,  78,  167]). 

Rendezvous.  The  process  of  rendezvous  with  an  AP  in  given  area  typically  occurs  by 
listening  for  beacons  transmitted  by  APs  nearby  or  by  broadcasting  wild  card  query  probes 
and  listening  for  responses.  Once  an  AP  is  discovered,  the  user  obtains  any  necessary 
credentials  to  access  the  AP  (e.g.,  by  paying  for  access),  typically  through  out-of-band 
means  (e.g.,  by  obtaining  a  password  from  a  web  service  or  the  AP’s  owner).  Then,  and 
after  subsequent  discovery  attempts,  the  user’s  device  can  automatically  authenticate  itself 
to  the  AP. 

Communicate.  Once  the  device  finishes  setting  up  the  connection  with  the  AP,  it  can 
communicate  with  and  through  it.  One  threat  to  location  privacy  comes  from  eavesdrop¬ 
pers  that  can  overhear  the  messages  sent  during  rendezvous  and  communication. 

Report.  Many  of  the  hotspot  directory  services  described  above  rely  on  reports  submitted 
by  users  to  populate  them  because  manually  cataloging  hotspots  across  many  geographic 
areas  is  too  burdensome.  Since  reports  contain  the  location  of  APs  that  users  have  used 
in  addition  to  user  identities,  another  potential  threat  to  location  privacy  comes  from  these 
directory  services. 


1.3  Thesis  Scope 

Section  1.1.3  outlined  the  three  classes  of  entities  that  might  obtain  our  location  informa¬ 
tion.  In  this  dissertation,  we  focus  on  techniques  that  mitigate  threats  from  eavesdroppers 
and  by  those  LBSes  used  for  the  discovery  of  wireless  networks,  as  there  are  already  incen¬ 
tives  and  mechanisms  for  ISPs  and  query-only  LBSes  to  protect  their  customers’  location 
information.  We  also  address  other  attacks  that  eavesdroppers  and  malicious  directory 
services  might  carry  out,  such  as  user  profiling  and  inventorying. 

Table  1.2  shows  which  entities  can  observe  identity  and  location  during  each  stage. 
Identity  may  be  revealed  by  explicit  or  implicit  identifiers  in  link-layer  or  higher-layer 
(IP  or  application  layer)  protocols.  Location  may  be  revealed  by  physical  proximity  (e.g., 
knowledge  that  a  device  is  nearby  due  to  its  limited  transmission  range)  or  by  a  device 
explicitly  reporting  it. 

Most  prior  work  on  protecting  location  privacy  has  focused  on  preventing  query-only 
LBSes  from  obtaining  identity,  location,  or  both. 
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Explicit  identifiers  in  LBS  queries.  The  traditional  mechanism  to  protect  privacy  in 
location  traces  is  to  replace  each  device  identity  with  a  pseudonym  [132]  (i.e.,  an  identifier 
that  can  not  be  traced  back  to  a  device).  For  example,  a  user  may  sign  into  an  LBS 
with  a  random  name  rather  than  with  his  real  name.  Unfortunately,  a  number  of  research 
studies  have  shown  that  using  pseudonyms  in  location  traces  is  often  insufficient  to  protect 
location  privacy  because  enough  contextual  information  remains  to  tie  a  location  trace 
to  a  specific  individual.  These  inference  attacks  have  been  effective  on  indoor  location 
traces  [27]  and  outdoor  GPS  location  traces  [75,  97].  It  has  also  been  shown  that  a  small 
number  of  location  traces  with  high-frequency  periodic  samples  can  be  disambiguated 
even  if  no  two  samples  were  linked  by  a  pseudonym  [64,  74,  166]. 

Self-reported  location  in  LBS  queries.  As  a  consequence,  there  have  also  been  a  num¬ 
ber  of  proposals  to  prevent  query-only  LBSes  from  collecting  accurate  location-traces 
from  their  users  by  adding  noise  to  self-reported  location.  Location  privacy  defenses  in¬ 
clude  having  users  submit  queries  with  lower  fidelity  [65,  28,  72,  114,  111],  with  lower 
frequency  [27,  75,  76],  with  added  noise  [97,  74,  173],  or  that  are  fake  [93]  to  make  a  col¬ 
lected  location  trace  too  inaccurate  to  be  useful.  Krum  [100]  and  Duckham  and  Kulik  [53] 
present  more  complete  surveys  of  the  privacy  issues  surrounding  query-only  LBSes  and 
location  trace  anonymization  in  general. 

Work  on  protecting  location  privacy  in  query-only  LBSes  is  important,  but  it  only  ad¬ 
dresses  one  phase  of  the  wireless  usage  model  (locating  service).  Merely  using  wireless 
mobile  devices  enables  undesirable  parties  such  as  eavesdroppers  to  collect  location  traces 
because  we  reveal  identity  and  location  to  many  other  entities  through  our  use  of  mobile 
devices.  Furthermore,  unlike  query-only  LBSes,  which  users  can  avoid  if  they  do  not 
provide  sufficient  privacy  guarantees,  the  processes  of  network  discovery  and  communi¬ 
cation  can  not  be  avoided  without  rendering  all  network-reliant  applications  useless.  This 
dissertation  focuses  on  this  more  fundamental  problem: 

How  we  can  build  wireless  protocols  and  discovery  services  in  ways  that  pro¬ 
tect  location  privacy? 

To  mitigate  location  privacy  threats,  either  identity  or  location  must  be  concealed  from 
the  entities  discussed  in  the  previous  section  that  are  undeterred  from  collecting  it:  eaves¬ 
droppers  and  crowd-sourced  LBSes,  in  particular.  Therefore,  we  focus  on  the  following 
three  problems: 

Explicit  identifiers  in  network  protocols.  Wireless  transmissions  have  limited  range. 
Therefore,  it  is  difficult  to  conceal  physical  proximity  from  eavesdroppers  because  receiv¬ 
ing  a  wireless  transmission  implies  that  a  device  is  nearby.  To  prevent  eavesdroppers  from 
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identity 

link-layer  higher-layer 

location 

physical  proximity  self-reported 

locate  service 

LBS 

(personalization 

/accounting) 

LBS 

(filtering  results) 

rendezvous 

eavesdroppers, 
ad-hoc  devices,  ISPs 
(device  discovery) 

ad-hoc  devices,  ISPs 
(device  discovery) 

eavesdroppers, 
ad-hoc  devices,  ISPs 
(limited  wireless  range) 

communication 

eavesdroppers, 
ad-hoc  devices,  ISPs 
(message  filtering) 

ad-hoc  devices,  ISPs 
(message  filtering) 

eavesdroppers, 
ad-hoc  devices,  ISPs 
(limited  wireless  range) 

report  on  service 

crowd-sourced  LBS 
(accountability) 

crowd-sourced  LBS 
(accurate  results) 

Table  1.2:  How  identity  and  location  is  revealed  during  different  stages  of  wireless  device 
usage.  Each  cell  lists  the  entities  that  can  observe  such  information  and,  in  parenthesis, 
the  primary  reason  why  the  information  is  revealed. 


tracking  devices,  a  device’s  transmissions  must  not  contain  any  information  that  identifies 
the  device.  Unfortunately,  nearly  all  wireless  protocols  today,  including  802. 11,  Bluetooth, 
WiMAX,  GSM,  and  RFID,  transmit  unique  and  device  addresses  in  many  of  the  packets 
transmitted  during  rendezvous  and  communication  (e.g.,  when  associating  in  Bluetooth 
and  GSM  and  in  all  packets  in  802. 11). 

Implicit  identifiers  in  network  protocols.  Even  if  explicit  identifiers  are  removed,  how¬ 
ever,  other  information  that  remains  exposed  in  packet  transmissions  may  reveal  a  de¬ 
vice’s  identity.  More  generally,  a  large  body  of  security  research  has  demonstrated  that 
side-channels  such  as  packet  sizes  and  inter-packet  timing  can  be  used  to  infer  hidden  in¬ 
formation  about  those  packets,  such  as  their  contents,  the  type  of  device  that  sent  them, 
etc.  Although,  simple  counter-measures  to  these  side-channel  attacks  have  been  proposed, 
such  as  by  adding  cover-traffic  and  packet  padding,  they  are  heavy-weight  and  substan¬ 
tially  degrade  performance. 

Explicit  identifiers  in  crowd-sourced  reports.  The  mechanisms  that  facilitate  service  lo¬ 
cation  (e.g.,  finding  an  AP)  may  pose  location  privacy  risks  because  they  are  often  crowd- 
sourced  EBSes  (e.g.,  AP  directories  such  as  JiWire  and  Hotspotr).  These  systems  are  in  the 
class  of  EBSes  that  are  also  recommender  systems.  That  is,  they  take  reports  on  localized 
service  (e.g.,  reports  on  an  AP)  from  user  volunteers  and  summarize  those  reports  to  give 
other  users  recommendations  nearby.  The  defenses  against  query-only  EBSes  discussed 
above  can  not  typically  be  applied  to  location-based  recommender  systems  because  they 
all  substantially  degrade  the  accuracy  of  location  information  collected,  rendering  col¬ 
lected  reports  useless. 
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1.4  Our  Contributions 


We  describe  previous  proposals  that  attempt  to  solve  each  of  these  three  problems  in  sub¬ 
sequent  chapters.  Prior  work  has  two  main  limitations  that  this  dissertation  redresses: 
First,  previous  solutions  address  the  parts  of  the  wireless  usage  model  in  a  piecemeal  fash¬ 
ion;  therefore,  applying  one  proposal  in  isolation  will  not  sufficiently  address  location 
privacy  threats  in  other  stages  of  the  usage  model.  It  is  a  non-trivial  exercise  to  stitch 
various  solutions  together.  Secondly,  no  previous  proposal  has  been  shown  to  be  practical 
when  applied  as  replacements  for  real  wireless  protocols  such  as  802.11.  This  dissertation 
studies  the  practical  problems  and  solutions  in  building  wireless  protocols  and  discovery 
services  by  actually  implementing  them.  We  make  three  major  contributions: 

1.  We  show  that  802. 1 1  eavesdroppers  can  track  users  using  only  logical-layer  implicit 
identifiers.  Therefore,  even  if  we  conceal  obvious  device  and  service  addresses, 
such  as  MAC  addresses,  using  pseudonyms  as  much  previous  work  has  proposed, 
eavesdroppers  can  still  carry  out  practical  tracking  attacks  using  commodity  hard¬ 
ware  [127]. 

2.  We  show  how  to  build  complete  and  practical  wireless  protocols  that  conceal  all 
explicit  identifiers,  substantially  mitigating  eavesdroppers’  ability  to  detect  implicit 
identifiers.  In  other  words,  we  show  that  such  protocols  can  have  the  same  func¬ 
tionality  and  efficiency  of  802.11,  and  also  conceal  all  transmitted  bits  in  mes¬ 
sages  [63,  129]. 

3.  We  show  that  it  is  feasible  to  build  recommender  LBSes  for  wireless  service  discov¬ 
ery  that  protect  the  location  privacy  of  users  that  contribute  reports,  yet  are  also  re¬ 
silient  to  malicious  users  that  submit  fraudulent  reports.  We  show  that  such  systems 
can  be  practical  alternatives  to  non-private  802.11  hotspot  directories  today  [128]. 


The  following  three  chapters  presents  our  work  for  each  contribution,  respectively, 
though  the  analysis  of  empirical  wireless  traffic,  novel  protocol  design,  and  detailed  eval¬ 
uation  of  prototype  implementations. 


1.5  Dissertation  Outline 

The  remainder  of  this  dissertation  is  organized  as  follows: 
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•  Chapter  2  demonstrates  that  previously  proposed  counter  measures,  when  applied 
to  existing  protocols  such  as  802.11,  are  insufficient  to  prevent  eavesdroppers  from 
collecting  accurate  location  traces,  thereby  necessitating  more  private  protocols. 

•  Chapter  3  demonstrates  how  to  build  complete  wireless  protocols  that  protect  loca¬ 
tion  privacy  from  eavesdroppers  by  presenting  the  design  and  evaluation  of  a  prac¬ 
tical  link-layer  protocol  that  makes  it  impractical  for  eavesdroppers  from  carry  out 
tracking  attacks. 

•  Chapter  4  demonstrates  how  crowd-sourced  LBSes  can  protect  location  privacy  in 
a  practical  manner  by  presenting  the  design  and  evaluation  of  a  privacy-preserving 
crowd-sourced  LBS  for  the  discovery  of  wireless  networks. 

•  Chapter  5  summarizes  the  contributions  of  this  dissertation  and  outlines  some  open 
problems. 
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Chapter  2 

Quantifying  Tracking  Threats 


The  best  practices  for  securing  802.11  networks,  embodied  in  the  802.  Hi  standard  [80], 
provide  user  authentication,  service  authentication,  data  confidentiality,  and  data  integrity. 
However,  they  do  not  provide  anonymity,  a  property  essential  to  prevent  location  tracking. 
It  is  trivial  to  track  an  802. 1 1  device  today  since  each  device  advertises  a  globally  unique 
and  persistent  MAC  address  with  every  frame  that  it  transmits.  In  response,  researchers 
have  proposed  applying  pseudonyms  [66,  84]  (temporary,  unlinkable  names)  to  mask  this 
identifier,  i.e.,  by  having  users  periodically  change  the  MAC  addresses  of  their  802.11 
devices. 

In  this  chapter,  we  demonstrate  that  short-term  pseudonyms  are  insufficient  to  provide 
prevent  the  tracking  of  802.11  devices.  Even  without  a  unique  address,  other  characteris¬ 
tics  of  users’  802. 1 1  traffic  can  identify  them  implicitly  and  track  them  with  high  accuracy. 
An  example  of  such  an  implicit  identifier  is  the  IP  address  of  a  service  that  a  user  frequently 
accesses,  such  as  his  or  her  email  server.  In  a  population  of  several  hundred  users,  this  ad¬ 
dress  might  be  unique  to  one  individual;  thus,  the  mere  observation  of  this  IP  address 
would  indicate  the  presence  of  that  user.  Of  course,  in  a  wireless  network  that  employs 
link-layer  encryption,  IP  addresses  would  not  be  visible  to  an  eavesdropper.  However, 
other  implicit  identifiers  would  remain  and  these  identifiers  can  be  used  in  combination  to 
identify  users  accurately. 

This  chapter  quantifies  how  well  a  passive  adversary  can  track  users  with  four  implicit 
identifiers  visible  to  commodity  hardware.  We  thereby  place  a  lower  bound  on  how  ac¬ 
curately  users  can  be  identified  implicitly,  as  more  implicit  identifiers  and  more  capable 
adversaries  exist  in  practice.  More  specifically,  we  identify  four  previously  unrecognized 
implicit  identifiers:  network  destinations,  network  names  advertised  in  802.1 1  probes,  dif¬ 
fering  configurations  of  802.11  options,  and  sizes  of  broadcast  packets  that  hint  at  their 
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contents.  We  then  develop  an  automated  procedure  to  identify  users.  This  procedure 
allows  us  to  quantify  how  much  information  implicit  identifiers,  both  alone  and  in  combi¬ 
nation,  reveal  about  several  hundred  users  in  three  empirical  802.11  traces. 

Our  evaluation  shows  that  users  emit  highly  discriminating  implicit  identifiers,  and, 
thus,  even  a  small  sample  of  network  traffic  can  identify  them  more  than  half  (56%)  of  the 
time  in  public  networks,  on  average.  Moreover,  we  will  almost  never  mistake  them  as  the 
source  of  other  network  traffic  (1%  of  the  time).  Since  adversaries  will  obtain  multiple 
traffic  samples  from  a  user  over  time,  this  high  accuracy  in  traffic  classification  enables 
them  to  track  many  users  with  even  higher  accuracy  in  common  wireless  networks.  For 
example,  an  adversary  can  identify  64%  of  users  with  90%  accuracy  when  they  spend  a 
day  at  a  busy  hot  spot  that  serves  25  concurrent  users  each  hour. 

Chapter  outline.  In  Section  2. 1  we  illustrate  the  power  of  implicit  identifiers  with  sev¬ 
eral  real  examples.  Section  2.2  discusses  prior  work  on  implicit  identifiers.  Section  2.3 
explains  our  experimental  methodology.  Section  2.4  describes  our  empirical  802. 1 1  traces. 
Section  2.5  analyzes  how  well  802.1 1  users  can  be  identified  using  each  implicit  identifier 
individually.  Section  2.6  examines  how  accurately  an  adversary  can  track  people  using 
these  implicit  identifiers  in  public,  home,  and  enterprise  networks.  We  conclude  this  chap¬ 
ter  in  Section  2.7. 


2.1  The  Implicit  Identifier  Problem 

How  significantly  do  implicit  identifiers  erode  location  privacy?  Consider  the  seem¬ 
ingly  innocuous  trace  of  802. 1 1  traffic  collected  at  the  2004  SIGCOMM  conference,  now 
anonymized  and  archived  for  public  use  [47].  Interestingly,  hashing  real  MAC  addresses 
to  pseudonyms  is  also  the  best  practice  for  anonymizing  traces  such  as  this.  Unfortunately, 
implicit  identifiers  remain  and  they  are  sufficient  to  identify  many  SIGCOMM  attendees. 
For  example: 

Implicit  identifiers  can  identify  us  uniquely.  One  particular  attendee’s  laptop  transmit¬ 
ted  requests  for  the  network  names  “MIT,”  “StataCenter,”  and  “roofnet,”  identifying  him 
or  her  as  someone  probably  from  Cambridge,  MA.  This  occurred  because  the  default  be¬ 
havior  of  a  Windows  laptop  is  to  actively  search  for  the  user’s  preferred  networks  by  name, 
or  Service  Set  Identifier  (SSID).  The  SSID  “therobertmorris”  perhaps  identifies  this  person 
uniquely  [137].  A  second  attendee  requested  “University  of  Washington”  and  “djw.”  The 
last  SSID  is  unique  in  the  SIGCOMM  trace  and  suggests  that  this  person  may  be  Univer¬ 
sity  of  Washington  Professor  David  J.  Wetherall,  one  of  our  coauthors.  More  distressingly. 
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Wigle  [167],  an  online  database  of  802.1 1  networks  observed  around  the  world,  shows  that 
there  is  only  one  “djw”  network  in  the  entire  Seattle  area.  Wigle  happens  to  locate  this 
network  within  192  feet  of  David  Wetherall’s  home. 

Implicit  identifiers  remain  even  when  counter  measures  are  employed.  Another  SIG- 
COMM  attendee  transferred  512MB  of  data  via  BitTorrent  (this  user  contacted  hosts  on 
the  typical  BitTorrent  port,  6881).  A  request  for  the  SSID  “roofnet”  [140]  from  the  same 
MAC  address  suggests  that  this  user  is  from  Cambridge,  MA.  Suppose  that  this  user  had 
been  more  stealthy  and  changed  his  or  her  MAC  address  periodically.  In  this  particular 
case,  since  the  user  had  not  requested  the  SSID  during  the  time  he  or  she  had  been  down¬ 
loading,  the  MAC  address  used  in  the  SSID  request  would  have  been  different  from  the 
one  used  in  BitTorrent  packets.  Therefore,  we  would  not  be  able  to  use  the  MAC  address 
to  explicitly  link  “roofnet”  to  this  poor  network  etiquette.  However,  the  user  does  access 
the  same  SSH  and  IMAP  server  nearly  every  hour  and  was  the  only  user  at  SIGCOMM  to 
do  so.  Thus,  this  server’s  address  is  an  implicit  identifier,  and  knowledge  of  it  enables  us 
to  link  the  user’s  sessions  together. 

Now  suppose  that  the  network  employed  link-layer  encryption  scheme,  such  as  WPA, 
that  obscures  network  addresses.  Even  then,  we  could  link  this  user’s  sessions  together  by 
employing  the  fact  that,  of  the  341  users  that  sent  802.11  broadcast  packets,  this  was  the 
only  one  that  sent  broadcast  packets  of  sizes  239,  245,  and  257  bytes  and  did  so  repeatedly 
throughout  the  entire  conference.  Furthermore,  the  identical  802.1 1  capabilities  advertised 
in  each  session’s  management  frames  improves  our  confidence  of  this  linkage  because 
these  capabilities  differentiate  different  802. 1 1  cards  and  drivers.  Prior  research  has  shown 
that  peer-to-peer  file  sharing  traffic  can  be  detected  through  encryption  [172].  Thus,  even 
if  pseudonyms  and  link-layer  encryption  were  employed,  we  could  still  implicate  someone 
in  Cambridge. 

In  the  remainder  of  this  chapter,  we  examine  how  the  shortcomings  of  wireless  proto¬ 
cols  impact  the  location  privacy  of  a  large  number  of  users  in  different  802. 1 1  networks 
and  demonstrate  that  the  examples  described  in  this  section  are  not  isolated  anomalies. 


2.2  Related  Work 

The  body  of  work  that  examines  inferring  information  from  implicit  side-channels  falls 
into  three  categories:  using  logical  layer  side-channels  to  fingerprint  devices,  using  logical 
layer  side-channels  to  infer  message  contents,  and  using  physical  layer  side-channels  to 
fingerprint  devices. 
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Logical  layer  fingerprints.  Seemingly  innocuous  information  such  as  packet  sizes,  tim¬ 
ing,  and  header  information  serve  as  fingerprints  that  identify  individual  devices  or  classes 
of  devices.  We  call  such  fingerprints  implicit  identifiers  because  they  can  implicitly  iden¬ 
tify  the  device  that  transmitted  a  sequence  of  messages  even  when  no  explicit  identifiers, 
such  as  MAC  addresses,  are  exposed.  For  example,  Kohno  et  al.  [95]  showed  that  devices 
could  be  fingerprinted  using  the  clock  skew  exposed  by  TCP  timestamps.  Padmanabhan 
and  Yang  [126]  explored  fingerprinting  users  with  “clickprints,”  or  the  paths  that  users 
take  through  a  website.  Security  tools  like  nmap  [61]  and  pOf  [125]  leverage  differences 
in  network  stack  behaviors  to  determine  a  device’s  operating  system. 

Although  this  work  demonstrates  serious  privacy  risks  with  the  release  of  IP  or  application- 
level  network  traces,  the  information  these  fingerprinting  techniques  rely  on  is  concealed 
by  link-layer  encryption.  Thus,  they  are  less  of  a  concern  for  properly  secured  wireless 
communications.  There  are  also  practical  limitations  that  limit  tracking  attacks  using  these 
implicit  identifiers  as  well.  Kohno  et  al.  note  that  one  limitation  of  their  work  is  that  an 
adversary  can  not  passively  obtain  timestamps  from  devices  running  the  most  prevalent 
operating  system,  Windows  XP.  For  example,  we  find  that  only  15%-32%  of  users  in  send 
TCP  timestamps  in  wireless  traces  that  we  analyze.  Padmanabhan  and  Yang’s  techniques 
rely  on  data  from  many  user  sessions  collected  at  actual  web  servers. 

In  contrast  to  these  IP  and  application  layer  implicit  identifiers,  Franklin  et  al.  [56] 
showed  that  it  is  possible  to  fingerprint  device  drivers  using  the  timing  of  802.11  probes. 
However,  it  is  not  yet  clear  how  well  individual  devices  can  be  distinguished  using  this 
implicit  identifier. 

By  addressing  these  limitations  in  this  chapter,  we  show  that  tracking  wireless  devices 
using  implicit  identifiers  exposed  in  wireless  protocols  is  practical.  These  three  research 
efforts  compliment  our  work,  since  the  procedure  we  develop  for  identifying  users  enables 
an  adversary  to  use  these  implicit  identifiers  in  combination  with  ours,  yielding  even  more 
accurate  user  fingerprints.  None  of  these  previous  efforts  offer  a  formal  method  to  combine 
multiple  pieces  of  evidence.  Moreover,  to  our  knowledge,  we  are  the  first  to  evaluate  the 
how  well  users  are  identified  by  implicit  identifiers  observed  in  empirical  wireless  data. 

Logical  layer  message  inference.  Implicit  identifiers  also  reveal  sensitive  information 
other  than  device  identity.  Key-stroke  dynamics  have  been  shown  to  accurately  identify 
users  [115,  147].  The  timing  and  sizes  of  Web  transfers  often  uniquely  identify  web¬ 
sites,  even  when  transmitted  over  encrypted  channels  [31,  150].  Finally,  there  has  been 
a  large  body  of  research  in  identifying  applications  from  implicit  identifiers  in  encrypted 
traffic  [90,91,  116,  172,  177]. 

It  is  important  to  note  that  many  of  these  side-channel  attacks  are  partly  enabled  by 
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the  presence  of  short-term  connection  (i.e.,  session)  identifiers.  This  is  because  they  rely 
on  analyzing  sequences  of  encrypted  messages  in  individual  connections.  Thus,  if  an 
eavesdropper  could  not  distinguish  the  messages  sent  in  different  connections,  these  side- 
channels  would  be  much  noisier  and  harder  to  extract  accurate  information  from.  We 
exploit  this  fact  in  our  solution  presented  in  Chapter  3. 

Physical  layer  fingerprints.  Physical  layer  information  may  also  sometimes  act  as  side 
channels  that  link  messages  together,  but  they  are  typically  less  accurate  than  logical  layer 
fingerprints  or  require  expensive,  non-commodity  hardware  to  detect.  For  example,  Tao  et 
al.  [153]  and  Bahl  and  Padmanabhan  [12]  show  that  signal  strength  measurements  from 
multiple  locations  can  be  used  to  distinguish  the  rough  locations  where  they  originated. 
Therefore,  when  devices  are  stationary,  they  can  approximately  distinguish  the  messages 
sent  by  each  one.  Nonetheless,  Bauer  et  al.  [18,  19]  find  that,  while  using  multiple  sig¬ 
nal  strength  measurements  to  distinguish  messages  sources  can  be  moderately  accurate, 
the  error  rate  is  sufficiently  high  that  certain  side-channel  attacks  (e.g.,  [105])  have  much 
lower  success  rates  (e.g.,  50%  vs.  95%).  Moreover,  collecting  sufficient  physical  layer  fin¬ 
gerprints  requires  multiple  monitoring  points  and  their  accuracy  can  be  reduced  by  varying 
a  client’s  transmit  power  [18,  19].  Patwari  et  al.  [131]  describe  a  similar  location  distin¬ 
guishing  physical  layer  fingerprint  based  on  measuring  a  device’s  multipath  signal  prop¬ 
agation  signature.  However,  it  is  not  possible  to  collect  these  signatures  with  commodity 
hardware  (software  defined  radios  were  used). 

Differences  in  radio  transients  induced  by  manufacturing  defects  in  different  radios 
might  also  be  used  to  fingerprint  devices.  Some  work  has  shown  this  to  be  true  at  least  for 
a  small  number  of  devices  [16,  70,  143].  Other  persistent  signal  and  modulation  differ¬ 
ences  induced  by  manufacturing  defects  can  be  used  to  accurately  fingerprint  devices  [36]. 
However,  all  these  fingerprinting  techniques  require  expensive  signal  analyzers  to  perform, 
so  only  well-funded  adversaries  are  likely  to  be  able  to  deploy  networks  of  these  monitors 
at  threatening  scales. 

This  dissertation  focuses  on  logical  layer  fingerprints  and  message  inference  and  does 
not  explicitly  address  physical  layer  implicit  identifiers.  Therefore,  an  eavesdropper  with 
specialized  equipment,  such  as  expensive  signal  analyzers,  may  still  be  able  to  track  users 
when  our  solutions  are  applied.  However,  it  is  much  less  likely  that  such  expensive  equip¬ 
ment  would  be  deployed  as  part  of  surveillance  networks  rather  than  commodity  hardware. 
Moreover,  our  solutions  are  a  necessary  first  step  in  defending  against  such  threats. 
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2.3  Experimental  Setup 


This  section  describes  the  evaluation  criteria  we  use  to  determine  how  well  several  implicit 
identifiers  can  be  used  to  track  users. 

The  Adversary.  Strong  adversaries,  such  as  service  providers  and  large  monitoring  net¬ 
works,  obviously  pose  a  large  threat  to  our  location  privacy.  However,  the  significance  of 
the  threat  posed  by  802. 1 1  is  that  anyone  that  wishes  to  track  users  can  do  so. 

Therefore,  we  consider  an  adversary  that  runs  readily  available  monitoring  software, 
such  as  t  cpdump  [156],  on  one  or  more  laptops  or  on  less  conspicuous  commodity  802.1 1 
devices  [165].  We  further  restrict  adversaries  by  assuming  that  their  devices  listen  pas¬ 
sively.  That  is,  they  never  transmits  802.11  frames,  not  even  to  associate  with  a  network. 
This  means  that  the  adversary  can  not  be  detected  by  other  radios.  The  adversary  deploys 
monitoring  devices  in  one  or  more  locations  in  order  to  observe  802. 1 1  traffic  from  nearby 
users.  By  considering  a  weak  adversary,  we  place  a  lower  bound  on  the  accuracy  with 
which  users  can  be  tracked,  as  stronger  adversaries  would  be  strictly  more  successful. 

The  Environments.  An  adversary’s  tracking  accuracy  will  depend  on  the  802.11  net¬ 
works  he  or  she  is  monitoring.  Since  implicit  identifiers  are  not  perfectly  identifying,  it 
will  be  more  difficult  to  distinguish  users  in  more  populous  networks.  In  addition,  differ¬ 
ent  networks  employ  different  levels  of  security,  making  some  implicit  identifiers  invisible 
to  an  adversary.  We  consider  the  three  dominant  forms  of  wireless  deployments  today: 
public  networks,  home  networks,  and  enterprise  networks. 

Public  networks,  such  as  hot  spots  or  metro-area  networks  [117],  are  typically  un¬ 
encrypted  at  the  link-layer.  Although  many  public  networks  employ  access  control — for 
example,  to  allow  access  to  only  a  provider’s  customers — most  do  so  via  authentication 
above  the  link-layer  (e.g.,  through  a  web  page)  and  by  using  MAC  address  filtering  there¬ 
after.  Very  few  use  802. 1  li-compliant  protocols  that  also  enable  encryption.  Hence,  identi¬ 
fying  features  at  the  network,  link,  and  physical  layers  would  be  visible  to  an  eavesdropper 
in  such  an  environment.  Unfortunately,  this  is  the  most  common  type  of  network  today 
due  to  the  challenge  of  secure  key  distribution. 

Home  and  small  business  networks  are  small,  but  detecting  when  specific  users  are 
present  is  increasingly  challenging  due  to  the  high  density  of  access  points  in  urban  ar¬ 
eas  [8].  In  addition,  these  networks  are  more  likely  to  employ  link-layer  encryption,  such 
as  WEP  or  WPA,  because  the  set  of  authorized  users  is  typically  known  and  is  small.  In 
cases  where  link-layer  encryption  is  employed,  an  eavesdropper  will  not  be  able  to  view 
the  payloads  of  data  packets.  However,  features  that  are  derived  from  frame  sizes  or  tim¬ 
ing,  which  are  not  masked  by  encryption,  or  from  802. 1 1  management  frames,  which  are 
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always  sent  in  the  elear,  remain  visible. 

Finally,  seeurity  eonseious  enterprise  networks  are  likely  to  employ  link-layer  eneryp- 
tion.  Moreover,  if  the  only  authorized  deviees  on  the  network  are  provided  by  the  eompany, 
there  will  be  less  diversity  in  the  behavior  of  wireless  eards.  For  example,  Intel  eorporation 
issues  similar  eorporate  laptops  to  its  employees.  We  eonsider  a  enterprise  network  where 
only  one  type  of  wireless  eard  and  eonfiguration  is  in  use,  so  users  ean  not  be  identified  by 
differenees  in  deviee  implementation.  However,  features  derived  from  the  networks  that 
users  visit  or  the  applieations  and  serviees  they  run  remain  visible. 

The  Monitoring  Scenario.  We  assume  that  users  use  different  pseudonyms  during  eaeh 
wireless  session  in  eaeh  of  these  environments,  as  Gruteser  et  al.  [66]  propose.  As  a  result, 
explieit  identifiers  ean  not  link  their  sessions  together.  Sessions  ean  vary  in  length,  so  we 
assume  that  every  hour,  eaeh  user  will  have  a  different  pseudonym.  We  define  a  trajfic 
sample  to  be  one  user’s  network  traffie  observed  during  one  hour. 

Although  it  is  possible  for  users  to  ehange  their  MAC  addresses  more  frequently,  this 
is  unlikely  to  be  very  useful  in  praetiee  beeause  other  features,  sueh  as  reeeived  signal 
strength,  ean  link 

pseudonyms  together  at  these  timeseales  [13,  154].  Moreover,  ehanging  a  deviee’s  MAC 
address  forees  a  deviee  to  re-assoeiate  with  the  aeeess  point  and,  thus,  disrupts  aetive  eon- 
neetions.  In  addition,  it  may  require  users  to  revisit  a  web  page  to  re-authentieate  them¬ 
selves,  sinee  MAC  addresses  are  tied  to  user  aeeounts  in  many  publie  networks.  Users  are 
unlikely  to  tolerate  these  annoyanees  multiple  times  per  session. 

Of  eourse,  the  ability  to  link  traffie  samples  together  does  not  help  an  adversary  deteet 
a  user’s  presenee  unless  the  adversary  is  also  able  to  link  at  least  one  sample  to  that  user’s 
identity.  In  Seetion  2.1,  we  showed  that  identity  ean  sometimes  be  revealed  by  eorrelating 
implieit  identifiers  with  out-of-band  information,  sueh  as  that  provided  by  the  Wigle  [167] 
loeation  database.  However,  if  the  adversary  knows  the  user  he  wishes  to  traek,  he  ean 
likely  obtain  a  few  traffie  samples  known  to  eome  from  that  user’s  deviee.  For  example,  an 
adversary  eould  obtain  sueh  samples  by  physieally  traeking  a  person  for  a  short  time.  We 
assume  the  adversary  is  able  to  obtain  this  set  of  training  samples  either  before,  during,  or 
after  the  monitoring  period.  Our  results  show  that  on  average,  only  1  to  3  training  samples 
are  suffieient  to  traek  users  with  eaeh  implieit  identifier  (see  Seetion  2.5.2).  The  monitor 
itself  eolleets  samples  that  the  adversary  wants  to  test,  whieh  we  eall  validation  samples. 

Evaluation  Criteria.  There  are  a  number  of  questions  an  adversary  may  wish  to  answer 
with  these  validation  samples.  Who  was  present?  When  was  user  U  present?  Whieh  sam¬ 
ples  eame  from  user  U?  Essential  to  answering  all  these  questions  is  the  ability  to  elassify 
samples  by  the  user  who  generated  them.  In  other  words,  given  a  validation  sample,  the 
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sigcomm 

training  validation 

ucsd 

training  validation 

training 

apt 

validation 

Duration  (hours) 

37 

54 

10 

11 

119 

345 

Total  Samples 

1974 

3391 

587 

1240 

638 

1473 

Frames  Per  Sample  (median) 

289 

284 

1227 

1128 

57 

92 

Total  Users 

377 

412 

225 

371 

97 

196 

Profiled  Users 

337 

337 

153 

153 

39 

39 

Samples  per  Profiled  User  (mean) 

5.5 

9.1 

3.1 

4.7 

14.7 

32.2 

Users  per  Hour  (mean) 

53 

64 

59 

113 

5 

4 

Table  2.1:  Summary  of  relevant  workload  statistics  and  parameters.  The  duration  reports 
only  hours  with  at  least  one  active  user. 


adversary  needs  to  answer  the  following  question  for  one  or  more  users  U : 

Question  1  Did  this  traffic  sample  come  from  user  U? 

Section  2.5  evaluates  how  well  an  adversary  can  answer  this  question  with  each  of  our 
implicit  identifiers. 

To  demonstrate  how  well  implicit  identifiers  can  be  used  for  tracking,  we  also  evaluate 
the  accuracy  in  answering  the  following: 

Question  2  Was  user  U  here  today? 

This  question  is  distinct  from  Question  1  because  an  adversary  can  observe  many  traffic 
samples  at  any  given  time,  any  one  of  which  may  be  from  the  target  user  U .  In  addition,  a 
single  affirmative  answer  to  Question  1  does  not  necessitate  a  affirmative  answer  to  Ques¬ 
tion  2  because  an  adversary  may  want  to  be  more  certain  by  obtaining  multiple  positive 
samples.  Section  2.6  details  the  interaction  between  these  questions  and  evaluates  how 
many  users  can  be  tracked  with  high  accuracy  in  each  of  the  802.11  networks  described 
above. 


2.4  Wireless  Traces 


We  evaluate  the  implicit  identifiers  of  users  in  three  802. 1 1  traces.  We  consider  s  i  gcomm, 
a  4  day  trace  taken  from  one  monitoring  point  at  the  2004  SIGCOMM  conference  [47], 
ucsd,  a  trace  of  all  802.11  traffic  in  U.C.  San  Diego’s  computer  science  building  on 
November  17,  2006  [43],  and  apt,  a  19  day  trace  monitoring  all  networks  in  an  apartment 
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building,  which  we  collected.  All  traces  were  collected  with  tcpdump-like  tools  and 
only  contain  information  that  can  be  collected  using  standard  wireless  cards  in  monitor 
mode.  The  ucsd  trace  is  the  union  of  observations  from  multiple  monitoring  points.  IP 
and  MAC  addresses  are  anonymized  but  are  consistent  throughout  each  trace  (i.e.,  there 
is  a  unique  one-to-one  mapping  between  addresses  and  anonymized  labels).  Link-layer 
encryption  (i.e.,  WEP  or  WPA)  was  not  employed  in  either  the  sigcomm  or  ucsd  net¬ 
work  and  neither  trace  recorded  application  packet  payloads.  In  our  analysis,  we  show 
that  implicit  identifiers  remain  even  when  we  emulate  link  layer  encryption  and  that  we 
do  not  need  packet  payloads  to  identify  users  accurately.  The  apt  trace  only  recorded 
broadcast  management  packets  due  to  privacy  concerns;  hence,  we  only  use  it  to  study  the 
one  implicit  identifier  that  is  extracted  from  these  packets. 

We  distinguish  unique  users  by  their  MAC  address  since  it  is  not  currently  common 
practice  to  change  it.  To  simulate  the  effect  of  using  pseudonyms,  we  assume  that  every 
user  has  a  different  MAC  address  each  hour.  Hence,  we  have  one  sample  per  user  for  each 
hour  that  they  are  active.  To  simulate  the  training  samples  collected  by  an  adversary,  we 
split  each  trace  into  two  temporally  contiguous  parts.  Samples  from  the  first  part  are  used 
as  training  samples  and  the  remainder  are  validation  samples.  We  choose  a  training  period 
in  each  trace  long  enough  to  profile  a  large  number  of  users.  For  the  sigcomm  trace,  the 
training  period  covers  the  time  until  the  end  of  the  first  full  day  of  the  conference.  For 
the  ucsd  trace,  the  training  period  covers  the  time  until  just  before  noon.  We  skip  one 
hour  between  the  training  and  validation  periods  so  user  activities  at  the  end  of  the  training 
period  are  less  likely  to  carry  over  to  the  validation  period.  For  the  apt  trace,  the  training 
period  covers  the  first  5  days.  We  consider  a  user  to  be  present  during  an  hour  if  and  only 
if  she  sends  at  least  one  data  or  802.11  probe  packets  during  that  time;  i.e.,  if  the  user  is 
actively  using  or  searching  for  a  wireless  network.^ 

Table  2.1  shows  the  relevant  statistics  about  each  trace.  Note  that  since  can  we  only 
compute  accuracy  for  users  that  were  present  in  both  the  training  and  validation  data,  those 
are  the  only  users  that  we  profile.  Therefore,  results  in  this  chapter  refer  to  ‘Profiled  Users’ 
as  the  total  user  count  and  not  ‘Total  Users.’ 


^We  ignore  samples  that  only  contain  other  802.11  management  frames,  such  as  power  management 
polls.  Including  samples  with  these  frames  would  not  appreciably  change  the  characteristics  of  the 
sigconun  workload,  but  would  double  the  number  of  total  “users”  in  the  ucsd  workload.  This  is  be¬ 
cause  many  devices  observed  in  the  ucsd  trace  were  never  actively  using  the  network;  we  ignore  these  idle 
devices. 
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2.5  Implicit  Identifiers 


In  this  section,  we  describe  four  novel  implicit  identifiers  and  evaluate  how  much  informa¬ 
tion  each  one  reveals.  Our  results  show  that  (1)  many  implicit  identifiers  are  effective  at 
distinguishing  individual  users  and  others  are  effective  at  distinguishing  groups  of  users; 
(2)  a  non-trivial  fraction  of  users  are  trackable  using  any  one  highly  discriminating  iden¬ 
tifier;  (3)  on  average,  only  1  to  3  training  samples  are  required  to  leverage  each  implicit 
identifier  to  its  full  effect;  and  (4)  at  least  one  implicit  identifier  that  we  examine  accurately 
identifies  users  over  multiple  weeks. 


2.5.1  Identifying  Traffic  Characteristics 

Network  Destinations.  We  first  consider  netdests,  the  set  of  IP  <address,  port>  pairs 
in  a  traffic  sample,  excluding  pairs  that  are  known  to  be  common  to  all  users,  such  as  the 
address  of  the  local  network’s  DHCP  server.  There  are  several  reasons  to  believe  that  this 
set  is  relatively  unique  to  each  user.  It  is  well  known  that  the  popularity  of  web  sites  has 
a  Zipf  distribution  [35],  so  many  sites  are  visited  by  a  small  number  of  users.  In  fact,  in 
the  sigcomm  and  ucsd  training  data,  each  <address,  port>  pair  is  visited  by  1.15  and 
1.20  users  on  average,  respectively.  The  set  of  sites  that  a  user  visits  is  even  more  likely 
to  be  unique.  In  addition,  users  are  likely  to  visit  some  of  the  same  sites  repeatedly  over 
time.  For  example,  a  user  generally  has  only  one  email  server  and  a  set  of  bookmarked 
sites  they  check  often  [155]. 

An  adversary  could  obtain  network  addresses  in  any  wireless  network  that  does  not 
enable  link  layer  encryption.  Even  if  users  sent  all  their  traffic  through  VPNs,  the  case 
for  several  users  in  the  sigcomm  trace,  the  IP  addresses  of  the  VPN  servers  would  be 
revealing.  No  application  or  network  level  confidentiality  mechanisms,  such  as  SSL  or 
IPSec,  would  mask  this  identifier  either. 

SSID  Probes.  Next  we  consider  ssids,  the  set  of  SSIDs  in  802.11  probes  observed  in  a 
traffic  sample.  Windows  XP  and  OS  X  add  the  SSID  of  a  network  to  a  preferred  networks 
list  when  the  client  first  associates  with  the  network.  To  simplify  future  associations,  sub¬ 
sequent  attempts  to  discover  any  network  will  try  to  locate  this  network  by  transmitting 
the  SSID  in  a  probe  request.  As  we  observed  in  Section  2.1,  SSID  names  can  be  distin¬ 
guishing.^  In  addition,  probes  are  never  encrypted  because  active  probing  must  be  able  to 

recent  patch  [113]  to  Windows  XP  allows  a  user  to  disable  active  probing,  but  it  remains  enabled  by 
default  because  disabling  it  would  break  association  in  networks  where  the  access  point  does  not  announce 
itself.  In  addition,  revealing  probes  or  beacons  are  still  required  for  devices  to  discover  each  other  in  ad  hoc 
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occur  before  association  and  key  agreement. 

There  are  two  practical  issues  that  limit  the  use  of  ssids  as  an  implicit  identifier.  First, 
the  preferred  networks  list  changes  each  time  a  user  adds  a  network,  and  thus  a  profile 
may  degrade  over  time.  Second,  clients  transmit  the  SSIDs  on  their  preferred  networks 
lists  only  when  attempting  to  discover  service.  Therefore,  clients  may  not  probe  for  distin¬ 
guishing  SSIDs  very  often.  While  this  is  true,  our  results  show  that  when  distinguishing 
SSIDs  are  probed  for,  they  can  often  uniquely  identify  a  user.  Since  all  users  in  the  mon¬ 
itoring  area  are  likely  to  use  the  SSIDs  of  the  networks  being  monitored,  these  SSIDs  are 
not  distinguishing  and  we  do  not  include  them  in  the  SSids  set. 

Broadcast  Packet  Sizes.  We  now  consider  beast,  the  set  of  802. 1 1  broadcast  packet 
sizes  in  each  traffic  sample.  Many  applications  broadcast  packets  to  advertise  their  exis¬ 
tence  to  other  machines  on  the  local  network.  Due  to  the  nature  of  this  function,  these 
packets  often  contain  naming  information.  For  example,  in  our  traces,  we  observed  many 
Windows  machines  broadcasting  NetBIOS  naming  advertisements  and  applications  such 
as  FileMaker  and  Microsoft  Office  advertising  themselves. 

Since  these  packets  vary  in  length,  their  sizes  can  reveal  information  about  their  content 
even  if  the  content  itself  is  encrypted.  Packet  sizes  alone  appear  to  distinguish  users  almost 
as  well  as  <application,  size>  tuples.  For  example,  in  the  sigeomm  trace,  there  are  only 
16%  more  unique  tuples  than  unique  sizes.  Table  2.2  lists  the  most  unique  broadcast 
packet  sizes  we  observed  and  the  application  port  that  generated  them.  Broadcast  packets 
are  sent  to  a  known  broadcast  MAC  address;  thus,  an  adversary  can  distinguish  them  from 
other  traffic  even  if  link  encryption  is  employed  and  the  adversary  is  not  granted  network 
privileges.  This  set  would  remain  identifying  even  when  user  behavior  changes  because 
most  broadcast  packets  are  emitted  automatically. 

Two  types  of  broadcast  packets,  standard  DHCP  requests  and  power  management  bea¬ 
cons,  are  common  to  all  users,  since  a  device  must  send  a  DHCP  request  in  order  to  obtain 
an  IP  address  and  sends  power  management  beacons  when  in  low  power  mode.  Thus,  we 
do  not  include  these  packets’  sizes  in  the  bcast  set.  These  packets  have  distinct  sizes  (336 
and  36  payload  bytes,  respectively)  so  they  can  be  filtered  even  when  link-layer  encryption 
is  enabled. 

MAC  Protocol  Fields.  Finally,  we  consider  fields,  the  specific  combination  of  802.11 
protocol  fields  visible  in  the  MAC  header  that  distinguish  a  user’s  wireless  card,  driver,  and 
configuration.  The  fields  included  are  the  ‘more  fragments,’  ‘retry,’  ‘power  management,’ 
and  ‘order,’  bits  in  the  header,  the  authentication  algorithms  offered,  and  the  supported 

mode. 
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Application 

Port 

Number  of  Sizes 

wireless  driver  or  OS 

NA 

14 

DHCP 

67 

14 

sunrpe 

111 

1 

NetBIOS 

138 

7 

groove-dpp 

1211 

1 

Microsoft  Office  v.X 

2222 

1 

FileMaker  Pro 

5003 

7 

X  Windows 

6000 

1 

Table  2.2:  A  list  of  the  most  unique  broadcast  packets  observed  in  the  sigcomm  trace. 
The  third  column  shows  the  number  of  packet  sizes  that  were  emitted  by  at  most  2  users. 

transmission  rates.  Some  card  configurations  can  be  more  or  less  likely  to  emit  different 
values  in  each  of  these  fields,  so  they  can  distinguish  users  with  different  wireless  cards. 
Although  this  identifier  is  unlikely  to  distinguish  users  uniquely,  it  can  be  combined  with 
others  to  add  more  evidence.  Moreover,  many  of  these  fields  are  available  in  any  802. 1 1 
packet,  so  they  can  almost  always  assist  in  identification.  Furthermore,  the  likelihood  of 
any  particular  field  combination  is  unlikely  to  change  for  a  user  unless  she  obtains  a  new 
wireless  device  or  driver;  thus,  fields  should  remain  identifying  over  long  time  periods. 


2.5.2  Evaluating  User  Distinctiveness 

To  show  much  information  each  identifier  reveals,  we  now  evaluate  how  accurately  an 
adversary  can  answer  Question  1  (see  Section  2.3)  using  each  implicit  identifier. 


Methodology 

We  construct  a  classifier  Cu  for  each  user  U  in  our  traces.  Given  a  traffic  sample  s,  Cu  re¬ 
turns  “Yes”  if  it  believes  the  sample  came  from  user  U  and  “No”  otherwise.  We  use  a  naive 
Bayes  classifier  due  to  its  effectiveness  in  application  traffic  classification  [116,  172,  177]. 
More  sophisticated  classifiers  exist,  but  this  simple  one  is  sufficient  to  demonstrate  that 
implicit  identifiers  are  a  problem.  Specifically,  from  each  traffic  sample,  we  extract  a 
vector  of  features  (/i, . . . ,  fm)-  In  our  case,  m  <  4,  one  feature  per  implicit  identifier 
present  in  the  sample.  Each  of  our  features  has  a  different  source,  so  we  assume  that  they 
are  independent.  For  each  feature  /*,  we  estimate  the  posterior  probability  distribution 
Pr[s  has /i|s  is  from  f/]  and  the  prior  probability  distribution 
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Pr[s  has  /*]  from  training  data.  We  are  interested  in 

Pr[s  is  from  U\s  has  /i, . . . ,  fm]  = 

nr  (Prl-s  has  fi\s  is  from  U])  ■  Pr[s  is  from  U] 
nr  Pr[s  has  fi] 

We  classify  a  sample  as  being  from  U  if  and  only  if  this  value  is  greater  than  a  threshold  T. 
We  also  estimate  the  prior 

Pr[s  is  from  U]  from  training  data,  though  this  could  also  be  based  on  a  priori  knowledge 
of  how  frequently  the  adversary  believes  his  target  will  be  present. 

Feature  Generation.  To  compute  these  probabilities,  we  must  convert  each  of  our  im¬ 
plicit  identifiers  into  a  categorical  or  real-valued  feature.  We  treat  the  fields  identifier  as  a 
categorical  feature  by  having  each  field  combination  represent  a  different  value.  Each  of 
the  other  three  identifiers  is  defined  as  a  set  of  discrete  elements',  e.g.,  netdests  is  a  set 
of  network  addresses.  The  following  procedure  describes  how  this  set  is  converted  into  a 
real-valued  feature  that  measures  how  similar  it  is  to  the  target  user’s  expected  set. 

We  first  construct  a  profile  set,  Profileu,  comprising  all  the  elements  in  the  union  of 
all  training  samples  for  user  U.  To  obtain  a  numeric  value  from  the  set  of  elements  from 
a  sample  s.  Sets,  we  use  a  weighted  version  of  the  Jaccard  similarity  index  [159]  of  the 
profile  and  the  sample  sets.  The  Jaccard  index  of  two  sets  computes  J{X,  Y)  = 
However,  some  elements  in  each  set  are  more  discriminating  than  others  (i.e.,  those  that 
we  observe  in  fewer  users’  traffic).  Hence,  we  weight  each  element  e  by  w{e),  the  inverse 
of  the  number  of  users  that  accessed  it.  We  learn  these  weights  from  the  training  data. 
Hence,  given  the  profile  Profileu,  the  feature  we  compute  for  sample  s  is: 

featureuis)  = 

/—/edProfileijVJSets 

This  value  quantifies  how  similar  the  set  seen  in  the  sample  is  to  the  user’s  profile.  Since 
this  procedure  computes  a  real-valued  feature,  we  estimate  the  probability  distributions 
using  a  density  estimator.  We  use  the  default  estimator  in  the  R  statistical  package  [135], 
which  uses  multiple  Gaussian  kernels. 

Accuracy  Metrics 

Implicit  identifiers  are  not  perfectly  identifying.  Therefore,  to  evaluate  Question  1,  we 
quantify  the  accuracy  of  our  classifier.  Accuracy  has  two  components:  (1)  the  true  positive 
rate  (TPR),  or  the  fraction  of  validation  samples  that  user  U  generates  that  we  correctly 
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fields 


Classifier  threshold  T 


Figure  2.1:  Mean  TPR  and  FPR  as  the  elassifier  threshold  T  is  varied  for  fields. 


fields 


Classifier  threshold  T 


Figure  2.2:  CCDF  of  elassifier  thresholds  T  that  aehieve  FPR  =  0.01  for  different  users 

elassify,  and  (2)  the  false  positive  rate  (FPR),  or  the  fraetion  of  validation  samples  that  user 
U  does  not  generate  that  we  ineorreetly  classify.  The  former  tells  us  how  often  (7’s  traffic 
will  identify  her,  while  the  later  tells  us  how  often  we  will  mistake  U  as  the  source  of  other 
traffic.  We  measure  accuracy  with  TPR  and  FPR  instead  of  just  precision  (i.e.,  the  fraction 
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Fraction  of  users  trainable 

sigcomm  ucsd 

netdests 

0.89 

0.84 

ssids 

0.81 

0.55 

beast 

0.70 

0.65 

fields 

1.00 

1.00 

Table  2.3:  The  fraetion  of  profiled  users  that  we  eould  train  using  eaeh  feature. 


of  all  samples  elassified  eorreetly)  beeause  the  vast  majority  of  samples  are  negative  (i.e., 
not  from  the  target  user).  Henee,  elassifiers  that  mark  a  larger  fraetion  samples  as  negative 
would  seore  higher  in  preeision  even  if  they  marked  the  same  fraetion  of  true  positives 
ineorreetly. 

Trainable  Users.  When  evaluating  eaeh  identifier,  we  eonsider  only  those  users  that  have 
at  least  one  training  sample  that  eontain  it,  sinee  we  ean’t  build  profiles  for  those  with  no 
sueh  samples.  Table  2.3  shows  the  number  of  profiled  users  that  exhibit  eaeh  feature  in 
the  training  period.  Eaeh  implieit  identifier  is  exhibited  by  a  different  subset  of  users.  In 
both  workloads,  eaeh  implieit  identifier  is  exhibited  by  a  majority  of  profiled  users.  The 
fraetion  of  users  that  exhibited  the  ssids  feature  is  lower  in  the  ucsd  workload  (55%  vs 
81%)  beeause  fewer  users  sent  SSID  probes  to  search  for  a  network.  This  may  be  because 
many  ucsd  users  already  established  a  high  preference  for  the  UCSD  network,  having 
used  it  previously,  sigcomm  users  were  all  new  to  the  SIGCOMM  network  and  initiated 
broader  searches  for  their  preferred  networks  before  association. 

Classifier  Thresholds.  We  evaluate  each  classifier  across  several  thresholds  T  in  order 
to  determine  the  trade-off  between  TPR  and  FPR.  As  T  increases,  FPR  and  TPR  decrease 
because  the  classifier  requires  more  evidence  that  a  user  is  present  in  order  to  answer 
positively.  This  is  exemplified  in  Figure  2. 1  for  the  classifier  using  the  fields  feature.  We 
assume  that  an  adversary  desires  a  target  FPR,  such  as  1  in  100,  and  chooses  a  threshold 
T  based  on  that  target.  Ideally,  the  target  FPR  would  be  low.  Due  to  variance  in  each 
user’s  training  data,  an  adversary  may  need  to  use  different  thresholds  to  achieve  the  same 
FPR  for  different  users.  This  is  exemplified  in  Figure  2.2,  which  shows  a  complementary 
cumulative  distribution  function  (CCDF)  of  thresholds  that  achieve  FPR  =  0.01  for  each 
user’s  classifier  using  the  fields  feature.  An  adversary  would  train  a  different  classifier  for 
each  user  that  he  is  tracking.  In  practice,  an  adversary  would  have  to  select  T  without  a 
priori  knowledge  of  the  FPR  achieved  on  the  validation  data.  In  Section  2.6.1,  we  show 
that  an  adversary  can  select  T  to  achieve  a  desired  FPR  without  this  knowledge  when  using 
multiple  features  in  combination. 
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(a) 


FPR  =  0.01 


□  sigcomm  □  uosd 


(b) 


FPR  =  0.1 


netdests  ssids  beast  fields 

□  sigcomm  □  ucsd 


T rue  positive  rate 


True  positive  rate 


Figure  2.3:  Classification  accuracy  using  each  feature.  The  top  two  graphs  show  the  mean 
achieved  TPR  for  (a)  FPR  =  0.01  and  (b)  FPR  =  0.1.  The  line  above  each  bar  show  the 
maximum  expected  TPR  given  a  perfect  classifier  on  that  feature.  The  bottom  two  graphs 
show  a  CCDF  of  the  achieved  TPR  on  sigcomm  users  for  (c)  FPR  =  0.01  and  (d)  FPR  = 

0.1. 


Results 

In  order  to  examine  the  characteristics  of  each  individual  implicit  identifier,  we  now  focus 
on  the  TPR  achieved  for  different  FPR  targets  using  each  identifier  in  isolation. 

Mean  Accuracy.  Figure  2.3(a)  and  (b)  shows  the  mean  TPR  achievable  with  each  im¬ 
plicit  identifier  in  isolation  for  FPR  =  0.01  and  FPR  =  0.1,  respectively.  For  example,  when 
using  netdests,  we  can  identify  samples  from  the  average  user  in  both  workloads  about 
60%  of  the  time  for  FPR  =  0.01 .  The  line  above  each  bar  indicates  the  maximum  expected 
TPR  that  a  perfect  classifier  would  achieve  on  that  implicit  identifier — i.e.,  a  classifier  that 
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always  classifies  a  sample  eorreetly  if  it  has  that  implieit  identifier,  but  guesses  randomly 
otherwise.  This  line  is  below  1.0  beeause  some  validation  samples  do  not  eontain  a  partie- 
ular  implieit  identifier  and,  henee,  even  a  perfeet  elassifier  on  this  identifier  would  not  do 
better  than  random  guessing  on  those  samples.  For  example,  many  samples  have  no  SSID 
probes  and,  thus,  are  missing  the  ssids  identifier. 

Figure  2.3(a)  shows  that  the  average  user  sometimes  emits  an  implieit  identifier  that  is 
highly  distinguishing,  netdests,  SSids,  and  bcast  all  aehieve  moderate  TPRs  (about  60%, 
18%,  and  30%,  respeetively)  even  for  a  very  low  FPR  (1%).  The  lower  TPR  for  ssids  is 
expeeted,  sinee  users  usually  only  emit  distinguishing  SSIDs  when  they  are  searehing  for 
a  network.  Indeed,  the  theoretieal  maximum  TPR  aehievable  by  a  perfeet  elassifier  is  only 
about  40%.  Also,  as  expeeted,  fields  is  not  able  to  identify  many  samples  on  its  own  sinee 
it  only  distinguishes  wireless  eards  and  drivers. 

Figure  2.3(b)  shows  that  the  TPR  for  fields  improves  to  40%  and  60%  when  FPR  = 
0.1,  for  the  sigcomm  and  ucsd  workloads,  respeetively.  Thus,  the  fields  identifier  is 
good  at  elassifying  users  into  groups,  and  ean  aid  in  identifying  users  in  those  eases  when 
no  unique  identifier  is  observed.  This  is  expeeted,  sinee  fields  only  distinguishes  wireless 
eards  and  divers.  The  TPR  of  the  other  three  features  improves  mueh  less  dramatieally 
when  we  inerease  the  allowable  FPR  from  0.01  to  0.1.  This  is  beeause  most  of  the  other 
implieit  identifiers  either  uniquely  identify  a  user,  or  are  not  identifying  at  all.  Thus,  the 
TPR  gains  observed  when  we  inerease  FPR  are  mostly  due  to  less  eonservative  random 
guessing  on  the  remaining  samples. 

This  effeet  ean  be  seen  in  Figure  2.4,  whieh  shows  the  variation  in  mean  TPR  and 
FPR  aeross  elassifieation  thresholds  for  sigcomm  users.  The  x  =  y  line  shows  how 
well  random  guessing  is  expeeted  to  perform.  The  TPR  of  all  the  features  exeept  for 
fields  grows  roughly  linearly  toward  1.0  after  the  initial  spike,  whieh  is  the  effeet  that 
progressively  less  eonservative  random  guessing  would  have. 

For  all  features,  users  in  the  ucsd  workload  are  slightly  more  identifiable  than  those  in 
the  sigcomm  traee.  This  is  probably  because  there  are  more  total  users  in  the  sigcomm 
workload  and,  thus,  a  higher  likelihood  that  two  users  exhibit  the  same  traits.  We  examine 
the  effect  population  size  has  on  tracking  in  Section  2.6.2. 

Variation  Across  Users.  Accuracy  for  some  users  is  better  than  others.  Thus,  Fig¬ 
ure  2.3(c)  and  (d)  shows  a  CCDF  of  achieved  TPR  over  all  users  in  the  sigcomm  work¬ 
load,  for  FPR  =  0.01  and  FPR  =  0.1,  respectively.  For  example,  consider  netdestS  when 
FPR  =  0.01.  In  this  case,  65%  of  users  achieve  a  TPR  of  at  least  50%. 

Each  of  the  first  three  implicit  identifiers  distinguishes  some  users  very  often.  Fig¬ 
ure  2.3(c)  shows  that  65%,  11%,  24%  of  users  have  samples  that  are  identified  at  least  half 
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FPR  vs  TPR 


Mean  false  positive  rate 


Figure  2.4:  The  mean  achieved  TPR  and  FPR  for  sigcomm  users  as  we  vary  the  classi¬ 
fication  threshold  T  using  each  feature  alone.  The  x  =  y  line  shows  how  well  random 
guessing  would  perform. 


of  the  time  with  an  FPR  of  only  0.01  using  netdests,  ssids,  and  bcast,  respectively.  This 
implies  that  a  non-trivial  number  of  users  are  trackable  even  if  only  one  of  these  features 
is  available. 

Nonetheless,  when  FPR  =  0.1,  12%,  53%,  and  29%  of  users  have  a  TPR  of  at  most  0.1 
as  well  using  netdestS,  bcast,  and  ssids,  respectively  (see  Figure  2.3(d)).  This  means 
that  our  classifier  does  not  perform  any  better  than  random  guessing  on  these  users.  These 
users  are  simply  not  identifiable.  For  example,  for  the  netdests  feature,  this  means  that 
these  users  only  visited  popular  destinations  during  the  training  period  or  did  not  revisit 
any  site  in  the  subsequent  days.  This  result  also  implies  that  the  mean  TPR  shown  in 
Figure  2.3(a)  and  (b)  actually  underestimates  the  TPR  for  the  users  that  are  identifiable  at 
all,  since  this  fraction  of  non-identifiable  users  drags  the  mean  down.  We  conclude  that 
there  is  a  large  variation  in  user  distinctiveness. 

Training  Sample  Sensitivity.  To  explore  the  variability  in  classifier  accuracy  for  different 
users,  we  examine  whether  users  observed  more  often  during  the  training  period  are  more 
identifiable.  Figure  2.5  shows  the  mean  TPR  achieved  for  FPR  =  0.01  for  sets  of  sigcomm 
users  with  different  numbers  of  training  samples.  The  error  bars  show  95%  confidence 
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Figure  2.5:  Sensitivity  to  the  number  of  training  samples  for  each  feature.  The  mean  TPR 
achieved  for  FPR  =  0.01  for  sigeomm  users  with  different  numbers  of  training  samples. 
The  error  bars  indicate  95%  confidence  intervals. 


intervals,  which  are  negligible  for  most  points. 

Figure  2.5  shows  that  the  mean  TPR  noticeably  increases  with  more  training  samples 
for  netdests  and  beast.  For  netdests,  TPR  stabilizes  after  3  training  samples.  The  TPR 
of  ssids  and  fields  does  not  change  dramatically  with  more  training  samples,  probably 
because  these  identifiers  are  generated  without  user  interaction  and,  thus,  are  nearly  always 
identical  when  emitted.  Artifacts  near  the  right  hand  side  of  each  graph,  such  as  large 
confidence  intervals,  are  mostly  due  to  small  sample  sizes  for  those  points.  We  conclude 
that  an  adversary  can  build  a  more  accurate  classifier  with  more  samples,  but  needs  very 
few  to  build  one  that  is  useful. 

Accuracy  Over  Time.  One  concern  is  that  the  accuracy  of  ssids  may  degrade  over 
time  since  a  user’s  preferred  networks  list  can  change.  Figure  2.6  shows  how  the  mean 
TPR  varies  over  two  weeks  in  the  apt  trace,  the  only  trace  of  that  duration,  fixing  FPR 
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Figure  2.6:  Accuracy  over  time.  Normalized  mean  TPR  on  each  day  in  the  apt  trace 
for  FPR  =  0.01.  Each  TPR  value  is  normalized  to  the  mean  TPR  for  the  entire  period, 
evaluated  over  the  users  present  during  that  day.  The  mean  TPR  for  the  entire  period  over 
all  profiled  users  is  42%. 


=  0.01.  Each  value  is  normalized  by  the  mean  TPR  for  the  entire  period.  Even  after  two 
weeks,  normalized  values  are  close  to  1,  which  suggests  that  the  SSIDs  that  users  emit  are 
relatively  stable  over  time. 


2.6  When  can  we  be  tracked? 

In  this  section,  we  evaluate  how  accurately  an  adversary  can  answer  Question  1  and  Ques¬ 
tion  2  in  each  of  the  wireless  environments  described  in  Section  2.3.  The  previous  section 
evaluated  how  well  an  adversary  could  use  implicit  identifiers  independently  to  determine 
whether  a  sample  came  from  a  given  user,  but  in  practice,  an  adversary  would  not  be 
restricted  to  using  identifiers  in  isolation. 

Without  link-layer  encryption,  public  networks  reveal  features  both  at  the  link  and 
network  layers.  In  contrast,  home  networks  that  employ  encryption  reveal  only  link-layer 
features.  Encrypted  enterprise  networks  comprised  of  homogeneous  devices  might  reveal 
only  link-layer  features  that  vary  due  to  application  and  user  behavior;  features  that  vary 
due  to  driver-  and  card-level  differences  provide  no  useful  information  since  they  would 
not  vary.  Therefore,  we  evaluate  each  environment  with  the  following  features  visible  to 
an  adversary: 

•  Public  network:  netdests,  ssids,  fields,  beast. 
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%  users  with  EPR  error  j  0.01 

median  error 

90th  percentile  error 

Public 

97% 

82% 

Home 

80% 

64% 

Enterprise 

79% 

68% 

Table  2.4:  Stability  of  classifier  threshold  T  across  different  validation  sub-samples.  The 
percentage  of  users  that  have  FPR  errors  that  are  less  than  0.01  away  from  the  target  FPR 
ofO.Ol. 

•  Home  network:  ssids,  fields,  beast. 

•  Enterprise  network:  ssids,  beast. 


Since  measurements  from  these  environments  can  be  difficult  to  obtain  due  to  legal 
and  ethical  restrictions,  we  use  our  analysis  of  the  sigeomm  trace  to  estimate  answers 
to  these  questions.  In  all  three  scenarios,  we  consider  users  with  devices  that  will  have  a 
different  pseudonym  each  hour  of  the  day  as  in  our  analysis  in  the  previous  section. 

Many  users  in  both  the  sigeomm  and  ucsd  traces  expose  implicit  identifiers  of  all 
four  types,  so  we  conjecture  that  populations  in  other  environments  are  unlikely  to  differ 
substantially  beyond  the  identifiers  available.  The  population  sizes  will  differ,  however,  so 
we  vary  the  population  size  in  our  experiments.  Enterprise  networks  may  be  more  homo¬ 
geneous,  but  the  identifiers  we  consider  vary  due  to  user  behavior  and  the  applications  that 
they  run.  SSids  will  remain  distinguishing  as  long  as  users  visit  other  networks  with  their 
devices,  and  beast  will  remain  distinguishing  as  long  as  laptops  run  Windows  and  use  or 
search  for  different  names,  since  a  large  number  of  broadcast  packets  are  due  to  NetBIOS. 


2.6.1  Ql:  Did  this  Sample  come  from  User  U? 

Eirst,  we  evaluate  how  well  an  adversary  can  answer  Question  1  using  features  in  com¬ 
bination.  Since  all  profiled  users  had  at  least  one  training  sample  with  each  of  the  four 
features  in  our  training  sets,  we  can  evaluate  the  accuracy  on  all  profiled  users,  not  just  a 
fraction,  as  was  the  case  when  using  individual  features  (see  Table  2.3). 

Eigure  2.7  shows  how  accurately  we  can  answer  Question  1  for  the  average  user  when 
varying  the  threshold  T  in  each  of  our  three  environments.  Eigure  2.8  shows  the  CODE  of 
TPR  achieved  for  users  in  public,  home,  and  enterprise  networks  for  several  EPR  =  0.01. 
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FPR  vs  TPR 


Mean  false  positive  rate 


Figure  2.7:  Classification  accuracy  for  Question  1  if  sigcomm  users  where  in  typical 
public,  home,  and  enterprise  networks. 

When  more  features  are  visible,  classification  accuracy  is  better.  In  public  networks, 
user  samples  are  identified  56%  of  the  time  with  a  very  low  FPR  (1%),  on  average.  This 
TPR  is  slightly  lower  than  that  observed  for  netdests  in  Figure  2.3(a)  because  here  we  are 
considering  all  users,  not  only  the  89%  that  exhibited  netdestS  in  their  training  samples. 
The  average  TPR  in  home  and  enterprise  networks  is  31%  and  26%,  respectively,  when 
FPR  =  0.01.  Figure  2.8  shows  that  when  FPR  =  0.01,  63%,  31%,  and  27%  of  users  are 
identifiable  at  least  50%  of  the  time  in  public,  home,  and  enterprise  networks,  respectively. 

As  expected,  users  are  more  identifiable  in  environments  with  more  features. 

Selecting  the  Classifier  Threshold.  As  mentioned  in  Section  2.5.2,  an  adversary  would 
have  to  select  a  classifier  threshold  T  to  achieve  a  desired  target  FPR.  In  practice,  he  would 
have  to  select  the  threshold  without  knowing  a  priori  the  resulting  FPR  of  the  validation 
data.  Instead,  an  adversary  would  have  to  choose  a  T  that  achieves  a  target  FPR  in  pre¬ 
vious  samples  he  has  collected  (e.g.,  as  part  of  training).  Therefore,  in  order  to  achieve 
the  desired  accuracy,  the  adversary  requires  that  the  T  chosen  in  this  manner  achieves 
approximately  the  FPR  target  in  yet  unknown  validation  data. 

To  test  whether  this  requirement  is  met,  we  ran  the  following  experiment  on  the  sigcomm 
workload:  An  adversary  selects  T  that  achieves  FPR  =  0.01  on  a  random  20%  subsample 
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FPR  =  0.01 


True  positive  rate 


Figure  2.8:  CCDF  of  TPR  for  Question  1  if  sigcomm  users  were  in  a  typieal  publie, 
home,  or  enterprise  network  for  FPR  =  0.01. 


of  the  validation  data  and  tests  whether  the  same  T  achieves  a  similar  FPR  in  a  different 
random  20%  subsample.  We  perform  10  trials  of  this  experiment  per  user  and  measure 
the  absolute  FPR  errors,  i.e.,  the  difference  between  the  achieved  FPR  and  the  target  FPR. 
Table  2.4  shows  the  number  of  users  that  have  median  and  90th  percentile  errors  that  are 
less  than  0.01  away  from  the  target  FPR.  79-97%  of  users  in  all  scenarios  have  errors  less 
than  0.01  away  from  the  target  most  of  the  time.  This  suggests  that  an  adversary  would  be 
able  to  select  T  that  achieves  an  FPR  very  close  to  a  desired  target  in  most  circumstances. 


2.6.2  Q2:  Was  User  U  here  today? 


Now  we  consider  Question  2.  We  consider  an  adversary  that  wants  to  accurately  detect 
the  presence  of  a  user  during  a  particular  8  hour  work  day.  In  this  section,  we  answer  the 
following  two  questions:  (1)  How  many  users  can  be  detected  with  high  confidence?  (2) 
How  often  does  a  user  have  to  be  active  in  order  to  be  detected? 
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Methodology 


Accuracy  Estimation.  Consider  an  environment  with  N  users  present  eaeh  hour  during 
an  eight  hour  day.  User  U  operates  a  laptop  during  active  different  hours  this  day  and  thus 
an  adversary  obtains  active  samples  from  U.  The  adversary  also  obtains  up  to  N  samples 
eaeh  hour  from  the  other  users. 

Suppose  an  adversary  would  like  to  determine  whether  U  is 
present  during  this  day  with  a  TPR  of  at  least  TPRtarget  and  an  FPR  of  no  more  than 
FPRtarget-  In  seetion  2.5.2,  it  was  shown  that  an  adversary  eould  use  features  in  eombina- 
tion  to  answer 

whether  a  partieular  traffie  sample  eame  from  U  with  a  moderate  TPR  (tpr-Qi)  and  a  very 
low  FPR  (fpvQi),  on  average.  Unfortunately,  even  a  very  low  fpvqi  eould  result  in  the 
miselassifieation  of  a  sample  beeause  during  an  eight  hour  day,  there  would  be  up  to  8iV 
opportunities  to  do  so.  Therefore,  to  boost  the  adversary’s  aeeuraey,  he  eould  answer 
Question  2  affirmatively  only  when  multiple  samples  are  elassified  as  being  from  U. 

Speeifieally,  suppose  the  adversary  only  answers  Question  2  affirmatively  when  at  least 
one  sample  from  belief  different  hours  is  elassified  as  from  U.  That  is,  he  believes  U  is 
present  during  at  least  belief  different  hours.  If  we  assume  that  the  observations  made 
during  eaeh  hour  are  independent,  when  U  is  aetive  during  at  least  active  >  belief  hours, 

TPRtarget  >  Pr[X  >  belief], 

where  X  is  a  binomial  random  variable  with  parameters  n  =  active  and  p  =  tpvgi.  In 
addition, 

FPRtarget  <  Pr[U  >  belief], 

where  U  is  a  binomial  random  variable  with  parameters  n  =  8  and  p  <  1  —  (1  —  fpvqi)^, 
the  probability  that  at  least  1  sample  not  from  U  during  one  hour  is  miselassified.  We  show 
below  that  the  independenee  assumption  is  not  unreasonable. 

In  order  for  an  adversary  to  answer  Question  2  with  TPRtarget  and  FPRtarget,  he 
would  determine  if  there  exists  a  threshold  T  for  IPs  elassifier  that  would  satisfy  these 
eonstraints.  In  the  proeess,  he  would  also  determine  the  minimum  number  of  hours  that 
U  would  have  to  be  active  (active).  For  example,  when  all  four  features  are  available,  we 
show  that  quite  a  few  users  can  be  detected  when  they  are  active  for  several  hours  even  if 
an  adversary  desires  99%  accuracy  (i.e.,  TPRtarget  >  99%  and  FPRtarget  <  !%)• 

Dependence.  The  constraints  above  assume  that  the  observations  made  during  each  hour 
are  independent.  That  is,  the  likelihood  of  observing  a  true  or  false  positive  is  not  depen- 
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Figure  2.9:  Limited  dependence  in  the  sigcomm  trace.  CDF  of  the  maximum  number  of 
false  positives  (FPs)  generated  by  any  one  user  for  each  user. 


dent  on  the  adversary’s  past  observations.  The  following  analysis  of  the  sigcomm  trace 
shows  that  there  is  some  dependence  in  reality,  but  that  the  dependence  is  small. 

There  are  two  primary  concerns.  The  first  concern  is  that  our  classifier  may  often 
confuse  user  U  with  another  user  Q,  so  that  if  Q  is  active,  then  the  false  positive  rate 
will  be  high  regardless  of  the  number  of  hours  that  the  adversary  samples.  This  concern 
is  mitigated  by  two  factors  that  add  randomness  to  the  sampling  process:  1)  users  enter 
and  depart  from  the  environment  and  2)  user  behavior  is  variable  to  begin  with.  Consider 
our  classifier  on  all  features  using  a  classification  threshold  T  =  0.5.  Figure  2.9  shows, 
for  each  user  that  exhibits  any  false  positives  during  the  second  full  day  of  the  sigcomm 
trace,  the  maximum  number  of  false  positives  that  are  contributed  by  any  other  single  user. 
From  this  cumulative  distribution  function  (CDF),  we  see  that  for  60%  of  users,  no  single 
other  user  is  responsible  for  more  than  1  false  positive,  and  for  over  95%,  no  single  user 
is  responsible  for  more  than  3  false  positives.  Therefore,  most  of  the  time  the  two  factors 
mentioned  prevent  a  large  number  of  false  positives  from  being  correlated  to  a  single  user. 
In  addition,  since  the  user  set  is  relatively  static  at  a  conference,  there  is  likely  to  be  more 
churn  in  the  population  of  most  other  environments,  further  reducing  the  dependence. 

The  second  concern  is  that  there  may  be  temporal  locality  in  either  true  or  false  positive 
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Temporal  Correlation 


Pr[pos|recent  pos]  /  Pr[pos] 


Figure  2.10:  Limited  dependence  in  the  s  igcomm  trace.  CDF  of  how  much  more  likely  a 
true  or  false  positive  is  given  that  one  was  observed  recently. 


samples.  For  example,  we  might  expect  that  a  user  is  much  more  likely  to  exhibit  a  par¬ 
ticular  feature  if  he  has  done  so  in  the  recent  past.  If  temporal  correlation  was  substantial 
then  the  ratio 


Pr  [positive  |  positive  in  the  last  t  hours] 

Pr  [positive] 

would  be  much  larger  or  smaller  than  1.  Figure  2.10  shows  a  CDF  of  this  ratio  for  each 
users’  true  and  false  positives  when  t  =  2  using  the  same  classifier  as  above.  For  true 
positives,  we  only  consider  times  during  which  the  user  is  active.  For  false  positives,  we 
only  consider  the  active  9  hours  of  the  last  2  days  of  the  conference  since  false  positives 
are  obviously  less  likely  to  occur  when  fewer  people  are  present.  If  there  was  no  temporal 
correlation,  we  would  obtain  a  vertical  line  at  x  =  1.  We  note  that  60  and  70%  of  users’ 
true  and  false  positives  are  within  a  factor  of  2  of  this  line,  meaning  that  if  a  true  (false) 
positive  was  seen  in  the  last  two  hours  we  are  no  more  than  2  times  more  or  less  likely 
to  observe  another  true  positive  than  otherwise.  Moreover,  given  the  small  number  of 
positives  for  each  user,  much  of  this  variation  is  probably  due  to  randomness.  Therefore, 
temporal  dependence  is  small. 
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Figure  2.11:  The  number  of  of  users  detectable  and  the  number  of  hours  they  must  be 
active  to  be  detected  with  (a)  90%  accuracy  and  (b)  99%  accuracy.  The  x-axis  in  each 
graph  varies  the  population  size.  The  top  portion  shows  the  number  and  percentage  of 
users  it  is  possible  to  detect.  The  bottom  portion  shows  a  box  plot  of  the  number  of  hours 
during  which  they  must  be  active  to  be  detected.  That  is,  the  thick  line  through  the  middle 
of  each  box  indicates  the  median,  the  ends  of  each  box  demark  the  middle  50%  of  the 
distribution,  and  the  whiskers  indicate  the  minimum  and  maximum  values. 

Results 

Figure  2.11  shows  the  number  of  users  detectable  and  the  number  of  hours  they  must  be 
active  to  be  detected  with  (a)  90%  accuracy,  (b)  99%  accuracy.  The  x-axis  in  each  graph 
varies  the  number  of  users  present  each  hour.  The  top  half  of  each  graph  shows  the  number 
of  users  an  adversary  can  detect  and,  above  each  bar,  the  percentage  of  profiled  users  the 
number  represents.  The  bottom  half  of  each  graph  shows  a  box  plot  of  the  number  of  hours 
during  which  these  users  must  be  active  to  be  detected.  That  is,  the  thick  line  within  each 
box  shows  the  median  number  of  hours  a  detectable  user  has  to  be  active  to  be  detected, 
while  the  ends  of  each  box  demark  the  first  and  third  quartiles.  The  whiskers  mark  the 
minimum  and  maximum. 
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For  example,  part  (a)  shows  the  results  if  the  adversary  desires  an  accuracy  of  90% 
(i.e.,  TPRtarget  >  90%  and  FPRtarget  <  10%).  Consldcr  the  public  networks  figure.  The 
fourth  bar  from  the  left  in  top  part  shows  that  when  there  are  10  users  present  per  hour,  we 
can  detect  71%  of  users  if  they  are  active  during  all  8  hours  when  present.  The  box  and 
whiskers  just  below  that  in  the  bottom  part  shows  that  shows  that  most  of  these  users  do 
not  need  to  be  active  all  8  hours  to  be  detected.  Of  the  71%  of  users  that  can  be  detected, 
75%  of  them  only  need  to  be  active  for  4  hours  to  be  detected,  50%  for  at  most  3  hours, 
and  25%  for  at  most  2  hours. 

Conclusions.  We  make  two  overall  conclusions.  First,  an  adversary  can  successfully 
combine  multiple  implicit  identifiers  from  a  few  samples  to  detect  many  users  in  common 
networks  with  high  accuracy.  The  majority  of  users  can  be  detected  with  90%  accuracy 
when  active  often  enough  in  public  networks  with  100  concurrent  users  or  less.  At  least 
27%  of  users  are  detectable  with  90%  accuracy  in  all  of  the  networks  when  there  are  25 
concurrent  users  or  less.  This  implies  that  many  users  can  be  detected  with  high  confidence 
in  small  to  medium  sized  networks  regardless  of  type  if  they  are  active  often  enough.  Even 
in  large  networks  with  100  users,  12%  to  52%  remain  detectable. 

Second,  some  users  are  detectable  with  very  high  accuracy.  Even  if  an  adversary  de¬ 
sires  99%  accuracy,  the  fraction  of  detectable  users  is  between  12%  and  37%  in  all  net¬ 
works  with  25  users  when  they  are  active  often  enough.  Therefore,  even  applying  existing 
best  network  security  practices  will  fail  to  protect  the  anonymity  of  a  non-trivial  fraction 
of  users. 

Indeed,  several  usage  patterns  in  home  and  enterprise  networks  make  detection  more 
likely  than  the  overall  results  suggest.  In  home  networks,  very  few  users  are  likely  to  be 
active  during  each  hour.  Eor  example,  even  when  monitoring  all  the  networks  in  our  apt 
trace,  we  only  observed  4  users  per  hour,  on  average.  Therefore,  the  results  closer  to  the 
left  side  of  each  graph  are  more  representative  of  home  environments.  Since  users  of  a 
enterprise  network  are  probably  employees,  they  are  more  likely  to  be  active  for  the  entire 
observation  period.  Thus,  the  top  half  of  each  graph  is  probably  a  good  estimation  of  the 
fraction  of  users  that  an  adversary  can  detect  on  a  typical  day. 


2.7  Summary,  Implications,  and  Limitations 

This  chapter  demonstrated  that  users  can  be  tracked  using  implicit  identifiers,  traffic  char¬ 
acteristics  that  remain  even  when  unique  addresses  and  names  are  removed.  Although 
we  found  that  our  technique’s  ability  to  identify  users  is  not  uniform — some  users  do  not 


42 


display  any  characteristics  that  distinguish  themselves  from  others — most  users  can  be  ac¬ 
curately  tracked.  For  example,  the  majority  of  users  can  be  tracked  with  90%  accuracy 
when  active  often  enough  in  public  networks  with  100  concurrent  users  or  less.  Some 
users  can  be  tracked  with  even  higher  accuracy.  Therefore,  pseudonyms  are  insufficient  to 
provide  location  privacy  for  many  users  in  802. 1 1  networks. 

Moreover,  our  results  showed  that  even  a  single  implicit  identifier,  such  as  netdests, 
ssids,  or  beast,  can  be  highly  discriminating  and  that  an  adversary  needs  only  1  to  3  sam¬ 
ples  of  users’  traffic  to  track  them  successfully,  on  average.  We  note  that  by  considering 
a  subset  of  all  possible  implicit  identifiers  and  a  weak,  passive  adversary,  our  results  only 
place  a  lower  bound  on  the  accuracy  with  which  users  can  be  tracked. 


2.7.1  Implications 

We  believe  our  study  illustrates  three  inherent  shortcomings  of  the  802.1 1  protocol  beyond 
exposing  explicit  identifiers,  none  of  which  is  trivially  fixed.  These  shortcomings  afflict 
not  only  802.11  but  many  wireless  protocols,  including  Bluetooth  and  ZigBee. 

Identifying  information  exposed  at  higher  layers  of  the  network  stack  is  not  ade¬ 
quately  masked.  For  example,  even  with  encryption,  packet  sizes  can  be  identifying. 
Padding,  decoy  transmissions,  and  delays  may  hide  information  exposed  by  size  and  tim¬ 
ing  channels,  but  increase  overhead.  For  example.  Sun  et  al.  [150]  found  that  8  to  16  KB 
of  padding  is  required  to  hide  the  identity  of  web  objects.  The  performance  penalty  due  to 
this  overhead  would  be  especially  acute  in  wireless  networks  due  to  shared  nature  of  the 
medium. 

Identifying  information  during  service  discovery  is  not  masked.  802. 1 1  service  dis¬ 
covery  can  not  be  encrypted  since  no  shared  keys  exist  prior  to  association.  This  raises 
the  more  general  problem  of  how  two  devices  can  discover  each  other  in  a  private  manner, 
which  is  expensive  to  solve  [1].  This  problem  arises  not  only  when  searching  for  access 
points,  but  also  when  clients  want  to  locate  devices  in  ad  hoc  mode,  such  as  when  using  a 
Microsoft  Zune  to  share  music  or  a  Nintendo  DS  to  play  games  with  friends. 

Identifying  information  exposed  by  variations  in  implementation  and  configuration 
is  not  masked.  Each  802. 1 1  implementation  typically  supports  different  802. 1 1  features 
(e.g.,  supported  rates)  and  has  different  timing  characteristics.  This  problem  is  difficult 
to  solve  due  to  the  inherent  ambiguity  of  human  specifications  and  manufacturers’  and 
network  implementors’  desire  for  flexibility  to  meet  differing  constraints. 

Balancing  the  costs  involved  in  rectifying  these  shortcomings  with  the  incentives  nec- 


43 


essary  for  deployment  is  itself  a  challenge.  Nonetheless,  rectifying  these  flaws  at  the 
protocol  level  is  important  so  that  users  need  not  limit  their  activities  in  order  to  protect 
their  location  privacy.  By  measuring  the  magnitude  with  which  each  flaw  contributes  to 
the  implicit  identifier  problem,  our  study  provides  insight  into  the  proper  trade-offs  to 
make  when  correcting  these  design  flaws  in  future  wireless  protocols.  We  describe  how 
future  protocols  should  address  these  problems  in  the  next  chapter.  In  the  short  term,  our 
study  may  give  guidance  to  individuals  that  are  willing  to  pro-actively  hide  their  identity 
in  existing  wireless  networks. 

2.7.2  Study  Limitations 

In  our  measurement  analysis,  we  relied  on  wireless  traces  with  durations  of  at  most  several 
days.  In  addition,  we  did  not  examine  wireless  traffic  from  some  common  environments 
such  as  hotspots.  We  do  not  believe  our  analysis  would  be  substantially  altered  in  these 
environments  because  most  of  the  implicit  identifiers  we  examined  are  generated  “auto¬ 
matically”  by  applications  running  on  a  device  rather  than  due  to  particular  user  behavior. 
In  addition,  our  longer-term  study  of  SSIDs  suggests  that  at  least  one  implicit  identifier 
is  stable  over  time.  This  matches  our  intuition  that  re-configuration  of  user  devices  and 
applications,  which  can  change  the  implicit  identifiers  a  device  exhibits,  occurs  rarely. 
Nonetheless,  it  would  still  be  useful  to  complement  our  study  with  a  longer-term  study  of 
wireless  traffic  from  users  in  more  diverse  environments  to  validate  these  conjecture  and 
to  understand  how  implicit  identifiers  may  evolve  over  time.  Such  a  study  would  aid  in 
understanding  whether  pseudonym  schemes  may  be  sufficient  to  mitigate  tracking  threats 
at  longer  time  scales  and  different  types  of  locations. 
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Chapter  3 

Mitigating  Eavesdropping  Threats 


Identifiers  and  addresses  have  always  played  important  roles  in  network  protocols.  For 
example,  the  structure  of  IP  addresses  is  critical  to  scalable  IP  routing.  In  addition,  ap¬ 
plication  layer  discovery  protocols  such  as  DNS  expose  identifiers  in  order  to  support 
rendezvous  between  clients  and  services.  Identifiers  in  IP,  transport,  and  application  layer 
protocols  pose  privacy  threats  to  users  when  eavesdroppers  can  intercept  messages  being 
routed  in  the  middle  of  networks,  e.g.,  by  ISPs  or  on  LANs  where  link  layer  traffic  is 
unencrypted.  For  example,  these  eavesdroppers  can  track  when  a  user  is  online  and  de¬ 
termine  which  parties  are  communicating.  A  number  of  defenses  have  been  developed 
to  guard  against  these  traffic  analysis  attacks,  such  as  mix  networks  [49]  and  cover  traf¬ 
fic  [68,  121,  161],  but  they  are  heavy-weight  and  incur  substantial  performance  penalties. 
Fortunately,  wired  networks  can  be  protected  with  physical  security  and  link  layer  encryp¬ 
tion,  and  only  powerful  adversaries  that  collude  with  ISPs  can  carry  out  eavesdropping 
attacks  in  the  middle  of  the  network. 

Wireless  link-layer  protocols,  however,  are  much  more  vulnerable  to  weak  adversaries 
because  anyone  can  eavesdrop  on  communications  from  devices  nearby  using  only  com¬ 
modity  hardware.  Although  link-layer  encryption  such  as  WPA  can  obscure  identifiers 
in  IP,  transport,  and  application  layer  protocols,  link-layer  protocols  such  as  802.11  and 
Bluetooth  expose  identifiers  themselves.  Two  types  of  identifiers  play  important  roles  in 
these  protocols  also: 


•  device/service  identifiers:  Device  and  service  identifiers  typically  persist  over  long 
time  scales  (months,  years,  or  longer)  and  are  transmitted  when  devices  try  to  set 
up  connections.  The  process  of  service  discovery  and  rendezvous,  such  as  with  an 
available  access  point  (AP),  requires  a  service  to  announce  its  existence  with  an 
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explicit,  recognizable  identifier  or  for  a  client  to  probe  for  it  (e.g.,  a  network’s  SSID 
and/or  BSSID  in  802.11).  Either  way,  the  process  relies  on  the  transmission  of  a 
service  name  explicitly. 

•  connection  identifiers'.  Connection  identifiers  or  addresses  are  used  to  identify  mes¬ 
sages  sent  by  the  two  devices  participating  in  a  connection.  Thus,  they  must  persist 
for  at  least  the  duration  of  a  connection.  A  destination  address  (802.11)  or  connec¬ 
tion  identifier  (WiMAX)  allows  a  device  to  decide  whether  it  is  the  destination  of 
a  message  by  using  a  simple  compare  operation.  Mechanisms  such  as  ARP  that 
translate  between  addresses  at  different  layers  rely  on  identifiers  that  persist  for  the 
duration  of  a  connection. 

In  the  previous  chapter,  we  showed  that  users  can  often  be  tracked  even  when  MAC 
addresses  periodically  changed.  This  is  because  eavesdroppers  can  still  observe  temporary 
addresses  and  network  names  in  transmissions  in  addition  to  other  traffic  properties  that 
serve  as  implicit  identifiers.  Concealing  specific  fields,  such  as  MAC  addresses,  leaves 
open  the  possibility  of  tracking  and  inventorying  by  other  fields  that  have  not  been  pro¬ 
tected.  Furthermore,  because  sequences  of  encrypted  packets  within  a  session  remain 
linked  by  a  connection  identifier,  side-channels  can  reveal  sensitive  information  about 
their  contents.  For  example,  a  distinct  pattern  of  packet  sizes  and  timings  is  sometimes 
sufficient  to  identify  the  keys  a  user  types  [147],  the  web  pages  he  views  [150],  the  videos 
he  watches  [142],  the  languages  he  speaks  [171],  and  the  applications  he  runs  [172].  In  this 
chapter,  we  present  the  first  design  and  prototype  of  a  wireless  protocol  that  conceals  all 
explicit  information  that  can  be  used  as  identifiers,  including  device  identifiers,  connection 
identifiers,  and  all  other  explicit  message  fields. 

The  obvious  difficulty  with  simply  removing  identifiers  is  that  they  play  key  roles  in 
the  efficient  operation  of  existing  protocols.  For  example,  a  connection  identifier  allows 
a  device  to  decide  whether  it  is  the  destination  of  a  message  by  using  a  simple  compare 
operation.  Mechanisms  such  as  ARP  that  translate  between  addresses  at  different  layers 
rely  on  identifiers  that  persist  for  significant  periods  of  time.  And  the  process  of  service 
discovery  and  rendezvous,  such  as  with  an  available  access  point  (AP),  requires  a  service 
to  announce  its  existence  with  an  explicit,  recognizable  identifier  or  for  a  client  to  probe 
for  it.  Either  way,  the  process  relies  on  the  transmission  of  a  service  name  explicitly. 

This  chapter  presents  SlyFi,  an  802. 11 -like  protocol  that  encrypts  entire  packets  to 
remove  explicit  identifiers  while  retaining  efficiency  comparable  to  802.1 1  with  WPA.  No 
explicit  information  in  SlyFi  messages  can  be  used  by  third  parties  to  link  them  together. 
We  show  that  all  features  that  rely  on  identifiers — service  discovery,  packet  filtering,  and 
address  binding — can  be  supported  without  exposing  them.  Different  mechanisms  are 
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used  for  service  discovery  and  subsequent  data  transfers,  but  in  both  cases  a  device  can 
determine  whether  it  is  the  recipient  of  a  message  with  lightweight  table  look-ups.  We  have 
implemented  SlyFi  on  commodity  802.11  NICs  and  our  experiments  show  that  SlyFi’s 
performance  impact  is  modest.  In  particular,  we  show  that  a  SlyFi  client  can  discover 
and  associate  with  services  even  faster  than  802.11  with  WPA  using  PSK  authentication. 
SlyFi’s  overhead  results  in  a  throughput  degradation  that  is  only  slightly  greater  than  that 
of  WPA  with  CCMP  encryption  (10%  vs.  3%). 

Chapter  outline.  Section  3. 1  discusses  the  limitations  of  previous  pseudonym  proposals. 
Section  3.2  presents  the  requirements  of  a  solution  and  an  overview  of  SlyFi.  Section  3.3 
presents  the  design  of  two  main  mechanisms  it  uses,  while  Section  3.4  discusses  practical 
details  and  our  prototype  implementation.  Section  3.5  demonstrates  SlyFi’s  security  prop¬ 
erties  formally  and  Section  3.6  analyzes  SlyFi’s  robustness  to  different  types  of  attacks. 
Section  3.7  presents  performance  evaluation  results.  Section  3.8  concludes  this  chapter. 


3.1  Related  Work 

A  number  of  proposals  have  argued  for  obscuring  identifiers  in  network  protocols  at  differ¬ 
ent  layers  of  the  protocol  stack.  These  proposals  advocate  for  three  types  of  pseudonyms: 
unilateral  pseudonyms,  negotiated  pseudonyms,  cryptographically  generated  pseudonyms. 

Unilateral  pseudonyms.  Some  wireless  protocol  identifiers  can  be  changed  over  time 
without  altering  the  functionality  of  a  wireless  protocol.  For  example,  in  802.11,  MAC 
addresses  serve  as  connection  identifiers  (source  and  destination  addresses),  but  persist  for 
the  lifetime  of  a  device’s  network  interface  hardware.  These  identifiers  can  be  changed 
by  a  device  without  negotiating  with  any  other  party  [67,  84,  170].  In  other  words,  they 
can  be  implemented  by  a  client  without  AP  support.  We  analyzed  the  limitations  of  using 
unilateral  MAC  address  pseudonyms  for  802.11  in  Chapter  2.  This  solution  is  insufficient 
because  service  identifiers  and  connection  identifiers  (e.g.,  SSIDs)  remain  exposed,  re¬ 
vealing  implicit  identifiers.  Moreover,  each  client  will  have  to  establish  a  new  connection 
with  an  AP  each  time  they  change  their  MAC  address,  disrupting  end-to-end  connections 
at  higher  layers. 

Negotiated  pseudonyms.  One  way  to  change  connection  identifiers  more  frequently  is 
to  have  both  ends  of  a  connection  (e.g.,  the  client  and  the  AP)  periodically  negotiate  a 
new  pseudonym.  For  example,  GSM’s  connection  identifier  for  a  client,  the  Temporary 
Mobile  Subscribed  Identifier  (TMSI),  can  be  refreshed  periodically  by  the  base  station. 
Negotiated  pseudonyms  can  also  be  used  to  make  device  identifiers,  such  as  a  GSM  mobile 
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phone’s  International  Mobile  Subscriber  Identity  (IMSI),  more  ephemeral.  In  GSM,  a 
mobile  phone  typically  must  transmit  its  globally  unique  IMSI  in  the  clear  to  identify  itself 
to  a  base  station  before  it  can  establish  a  connection.  Once  a  mobile  has  been  authenticated, 
however,  it  can  negotiate  a  new  IMSI  pseudonym  to  identify  itself  the  next  time  it  tries  to 
establish  a  connection  with  the  GSM  network  [73]. 

Explicitly  negotiated  pseudonyms  would  still  pose  two  problems  for  common  wireless 
protocols  such  as  802. 1 1  and  Bluetooth.  First,  because  both  ends  of  a  connection  must 
reliably  agree  on  the  new  pseudonym  before  it  can  be  used,  at  least  one  pair  of  messages 
must  be  exchanged.  This  would  add  substantial  overhead  if  very  frequent  pseudonym 
changes  are  desired  (e.g.,  on  a  per-message  basis).  Second,  when  used  in  discovery  and 
rendezvous,  at  least  one  party  to  the  rendezvous  may  transmit  the  same  pseudonym  mul¬ 
tiple  times  (e.g.,  [48]).  This  is  because  discovery  must  involve  probes  for  a  service  or 
announcements  from  the  service,  and  because  neither  the  client  or  the  service  can  negoti¬ 
ate  a  new  pseudonym  until  they  rendezvous  again,  any  probes  or  announcements  that  do 
not  elicit  a  response  must  be  repeated  with  the  same  pseudonym.  This  enables  eavesdrop¬ 
pers  to  track  at  least  one  party.  This  is  not  a  significant  concern  in  GSM  because  base 
stations  do  not  care  about  location  privacy;  thus,  they  can  authenticate  themselves  to  a 
mobile  phone  before  the  phone  reveals  its  own  identity.  However,  in  802. 1 1  and  Blue¬ 
tooth,  both  the  client  and  service  may  be  personal  mobile  devices  (e.g.,  a  mobile  phone 
communicating  with  a  laptop),  so  both  parties  require  location  privacy. 

One  way  to  mitigate  these  problems  is  to  negotiate  multiple  pseudonyms  for  each  de¬ 
vice  pair  and  use  one  per  message.  A  number  of  proposed  RFID  protocols  use  this  solu¬ 
tion.  RFID  protocols  involve  wireless  readers  and  tags,  where  the  role  of  tags  is  to  identify 
themselves  (e.g.,  with  a  serial  number)  to  readers  that  query  them.  No  other  information 
except  a  tag’s  device  identifier  is  transmitted,  so  RFID  protocols  are  comparable  to  basic 
discovery  protocols  in  802. 1 1  and  Bluetooth.  To  protect  a  tag’s  identifier  from  unautho¬ 
rized  readers,  researchers  have  proposed  storing  a  pseudonym  table  on  tags  and  authorized 
readers  [124,  87],  so  that  a  tag  can  emit  a  different  identifier  from  the  table  each  time  it 
is  queried.  One  problem  with  this  approach  is  that,  once  all  pseudonyms  in  the  table  are 
exhausted,  any  new  message  must  repeat  a  pseudonym.  Thus,  due  to  the  overhead  of  stor¬ 
ing  a  table  per  device  pair,  this  approach  is  impractical  when  the  number  of  messages  sent 
between  renegotiations  is  large  (e.g.,  for  high  volume  data  transfers)  or  can  be  unbounded 
(e.g.,  for  generic  discovery  messages). 

Cryptographic  pseudonyms.  A  number  of  cryptographic  schemes  have  been  proposed 
to  generate  pseudonyms  without  explicit  negotiation  for  each  pseudonym  change.  These 
schemes  typically  use  pseudorandom  sequences  or  public  key  cryptography. 
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Arkko  et  al.  [10]  and  Lindqvist  et  al.  [108]  argue  for  replacing  explicit  identifiers  at  all 
layers  of  the  network  stack  to  improve  privacy.  Arkko  et  al.  propose  replacing  identifiers 
in  messages  with  cryptographically  secure  pseudorandom  sequences,  where  each  message 
contains  a  new  element  from  the  sequence.  For  example,  for  a  sender  and  receiver  that 
share  a  symmetric  key,  Arkko  et  al.  show  how  identifiers  in  TCP  can  be  replaced  with 
pseudorandom  sequences.  Pseudorandom  sequences,  such  as  pseudorandom  functions 
(PRFs)  constructed  using  cryptographic  hash  functions  and  pseudorandom  permutations 
(PRPs)  constructed  using  symmetric  block  ciphers,  play  an  important  role  in  most  cryp¬ 
tographic  pseudonym  schemes  that  use  symmetric  keys,  including  SlyFi.  There  are  two 
main  research  questions  in  how  to  incorporate  pseudorandom  sequences  into  network  pro¬ 
tocols:  how  do  senders  and  receivers  synchronize  these  sequences,  and,  since  a  receiver 
must  store  one  symmetric  key  per  potential  sender,  how  can  they  scalably  maintain  and 
lookup  these  keys? 

Pseudorandom  sequence  schemes  have  been  proposed  for  use  in  a  number  of  specific 
protocols.  Some  proposed  RFID  protocols  [87,  163,  89]  use  pseudorandom  sequences  to 
compute  the  table  of  pseudonyms,  mentioned  above,  on  the  fly.  However,  these  proto¬ 
cols  disagree  on  how  synchronization  of  sequences  on  readers  and  tags  should  be  done. 
Cox  et  al.  [46]  uses  pseudorandom  sequences  for  an  application-level  discovery  protocol. 
Singelee  and  Preneel  [144]  propose  using  pseudorandom  sequences  to  replace  connection 
identifiers  in  Bluetooth.  Armknecht  et  al.  [11]  propose  using  them  in  encrypted  802.11 
headers.  Linqvist  et  al.  [107]  propose  a  pseudonym-based  discovery  protocol  that  avoids 
the  synchronization  problem  by  having  the  client  include  a  nonce  value  in  its  probe  that  is 
used  to  derive  the  cryptographic  pseudonym  in  a  service’s  response. 

While  each  of  these  proposals  address  particular  components  of  wireless  protocols, 
none  of  them  are  complete,  leaving  out  important  functions  such  as  either  service  discov¬ 
ery,  authentication,  data  transport,  higher-layer  binding,  etc.  Some  also  have  performance 
deficiencies.  For  example,  the  scheme  proposed  by  Cox  et  al.  uses  a  hash-chain  that 
evolves  with  real  time  to  compute  a  pseudorandom  sequence.  Thus,  a  device  that  is  asleep 
for  a  while  would  have  to  compute  every  intermediate  address  before  obtaining  the  current 
address  to  use.  This  application-layer  protocol  tolerates  this  extra  expense  because  its  ad¬ 
dresses  change  very  infrequently.  A  fundamental  problem  with  Linqvist  et  al.  ’s  approach 
is  that  it  requires  one  party  to  try  every  key  it  has  to  decode  a  message.  Therefore  it  is  in¬ 
efficient  when  a  receiver  has  many  keys  and  receives  packets  not  destined  for  it,  e.g.,  when 
it  sees  competing  background  traffic.  Similarly,  the  scheme  proposed  by  Armknecht  et 
al.  requires  a  receiver  to  try  every  key  it  has  to  decode  packets  with  no  matching  address. 
Therefore,  this  scheme  can  be  inefficient  in  real  environments. 

Cryptographic  schemes  based  on  public  key  cryptography  have  also  been  proposed 
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2.4 

7.1 

17.9 

76.6 
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Table  3.1:  Mean  number  of  devices  that  send  or  receive  802.11  data  packets  at  different 
time  intervals  at  two  conferences  (SIGCOMM  [138],  OSDI  [40])  and  one  office  building 
(UCSD  [43]).  Intervals  with  no  data  packets  are  ignored.  UCSD  has  observations  from 
multiple  monitors. 


to  protect  identifiers  in  discovery  and  rendezvous  messages.  For  example,  Abadi  and 
Fournet  [1]  present  a  public  key  scheme  for  private  authenticated  discovery.  Practical 
implementations  of  these  schemes  in  wireless  protocols  are  inefficient,  however,  due  to 
the  high  overhead  of  public  key  cryptography.  We  compare  pseudonym  schemes  based  on 
symmetric  and  public  key  cryptography  in  greater  technical  depth  in  Section  3.3.1. 

In  addition  to  the  limitations  enumerated  above,  very  few  of  these  cryptographic  pseudonym 
proposals  have  been  implemented  (only  [46],  to  our  knowledge).  Thus,  SlyFi  is  the  first  to 
show  that  real  devices  that  can  implement  these  proposals  in  a  practical  manner.  Practical 
implementations  are  important  to  understand  economic  feasibility  and  deployability. 


3.2  Problem  and  Solution  Overview 

Our  goal  is  to  build  a  wireless  link  layer  protocol  that  allows  clients  and  services  to  com¬ 
municate  without  exposing  identifiers  to  third  parties.  This  section  outlines  the  threat 
model  we  consider.  We  then  discuss  our  security  requirements  and  the  challenges  in  meet¬ 
ing  them  and  present  an  overview  of  SlyFi,  an  efficient  identifier-concealing  link  layer 
protocol  based  on  802. 1 1 . 

3.2.1  Threat  Model 

Attack.  The  previous  section  outlined  three  types  of  attacks  enabled  by  low-level  iden¬ 
tifiers  not  obscured  by  existing  security  mechanisms:  the  inventorying,  tracking,  and  pro¬ 
filing  of  users  and  their  devices.  Users  can  be  subjected  to  these  attacks  without  their 
knowledge  because  an  adversary  can  carry  them  out  without  being  visibly  or  physically 
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present.  In  addition,  users  are  vulnerable  even  when  using  the  best  existing  seeurity  prae- 
tiees,  sueh  as  WPA.  Thus,  these  attaeks  violate  eommon  assumptions  about  privaey.  The 
effeetiveness  of  these  attaeks  is  dependent  on  an  adversary’s  ability  to  link  paekets  sent  at 
different  times  to  the  same  deviee.  The  easiest  way  for  adversaries  to  link  paekets  is  by 
observing  the  same  low-level  identifier  in  eaeh. 

Thus,  our  goal  is  to  limit  two  forms  of  linkability:  First,  information  should  not  be  pro¬ 
vided  in  individual  paekets  that  explieitly  links  the  paekets  to  the  identities  of  the  sender 
or  intended  reeeiver.  Seeond,  to  prevent  the  profiling,  fingerprinting,  and  traeking  of  se- 
quenees  of  related  paekets,  paekets  from  the  same  sender  should  not  be  linkable  to  eaeh 
other,  irrespeetive  of  whether  any  one  of  them  may  be  linked  explieitly  to  its  souree.  In 
other  words,  when  there  are  k  potential  deviees  and  an  adversary  observes  a  paeket,  he 
should  only  be  able  to  infer  that  the  paeket  is  from  (or  to)  one  of  those  k  deviees,  not 
whieh  one.  Profiling  a  deviee’s  paeket  sequenees  would  be  more  diffieult  even  at  short 
timeseales  if  many  deviees  are  aetive  simultaneously.  Table  3.1,  whieh  shows  the  average 
number  of  aetive  deviees  observed  at  different  time  intervals,  shows  that  there  are  indeed 
many  simultaneously  aetive  deviees  in  three  802. 1 1  traees. 

Potential  Victims.  The  aforementioned  attaeks  are  damaging  to  both  wireless  elients, 
sueh  as  laptops,  and  wireless  serviees,  sueh  as  APs,  partieularly  sinee  the  distinetion  be¬ 
tween  elient  and  serviee  deviees  is  beeoming  inereasingly  blurred;  e.g.,  a  elient  game 
station  sometimes  provides  wireless  serviee  to  others  as  an  ad  hoe  AP.  Thus,  we  want  to 
limit  the  linkability  of  paekets  transmitted  by  both  elients  and  serviees. 

We  assume  that  elients  and  serviees  have  (possibly  shared)  eryptographie  keys  prior 
to  eommunieation.  These  keys  ean  be  obtained  in  the  same  way  as  in  existing  seeure 
802.11  and  Bluetooth  networks.  For  example,  deviees  ean  leverage  traditional  eredentials 
from  trusted  authorities  (e.g.,  for  RADIUS  authentieation)  or  bootstrap  symmetrie  keys 
using  out-of-band  pairing  teehniques  [152].  We  believe  that  most  private  serviees  will  be 
known  beforehand  (e.g.,  a  home  802.11  AP)  and  ean  bootstrap  keys  using  these  methods. 
Nonetheless,  in  previous  work  [129]  we  also  proposed  methods  to  privately  bootstrap  keys 
with  unknown  serviees  by  leveraging  transitive  trust  relationships. 

The  mere  possession  of  eryptographie  keys  does  not  immediately  yield  satisfaetory 
solutions,  however,  as  elients  and  serviees  have  limited  eomputational  resourees.  As  a 
eonsequenee,  solutions  should  not  enable  denial  of  serviee  attaeks  that  exploit  this  limita¬ 
tion.  For  example,  simply  enerypting  the  entirety  of  a  paeket  is  not  suffieient  if  a  reeeiver 
ean  not  quiekly  determine  whether  it  is  the  intended  reeipient  or  not.  This  is  because  an  ad¬ 
versary  would  then  be  able  to  exhaust  a  device’s  computational  resources  by  broadcasting 
“junk”  packets  that  the  device  would  expend  a  non-trivial  amount  of  resources  to  discard. 
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Adversary.  We  are  concerned  with  limiting  the  packet  linking  ability  of  eavesdroppers, 
i.e.,  parties  other  than  the  original  sender  or  intended  recipient  of  those  packets.  For  exam¬ 
ple,  packets  sent  between  an  802. 1 1  client  and  an  802. 1 1  AP  are  exposed  to  anyone  within 
radio  range,  but  only  the  client  and  service  should  be  able  to  link  them  together.  We  are 
not  concerned  with  preventing  the  service  from  linking  together  the  client’s  packets  (or 
vice  versa),  as  techniques  used  to  hide  a  client’s  identity  from  a  service  in  wired  networks 
(e.g.,  [50])  are  also  applicable  in  wireless  networks. 

We  assume  adversaries  have  commodity  802.1 1  radios  and  are  able  to  observe  all  trans¬ 
mitted  packets,  but  they  are  not  privy  to  the  cryptographic  keys  that  clients  and  services 
have  prior  to  communication.  As  with  most  practical  systems,  we  assume  that  adversaries 
are  computationally  bounded  and  thus  can  not  successfully  attack  standard  cryptosystems 
such  as  RSA,  ElGamal,  and  AES. 

Limitations.  SlyEi’s  removal  of  low-level  identifiers  makes  it  much  more  difficult  for 
third  parties  to  link  packets  together  or  to  a  particular  user,  thus  improving  privacy.  Nonethe¬ 
less,  packet  sizes,  packet  timings,  and  physical  layer  information  may  still  sometimes  act 
as  side  channels  that  link  packets  together.  We  briefly  discuss  SlyEi’s  resilience  to  these 
types  of  attacks  in  Section  3.6,  but  a  thorough  analysis  is  outside  the  scope  of  this  disser¬ 
tation.  However,  without  explicit  identifiers  linking  together  packets,  it  becomes  a  more 
difficult  probabilistic  task  to  separate  the  transmissions  of  different  sources.  Such  attacks 
are  less  accessible  as  they  usually  require  sophisticated  attackers  [153]  or  non-commodity 
hardware  [131]. 

We  note  that  packet  sizes  and  timing  can  be  hidden  using  well-known  packet  padding 
and  cover  traffic  techniques  that  make  all  packets  appear  uniform.  These  techniques  can 
be  applied  at  the  network  layer,  so  SlyEi  complements  them  by  encapsulating  their  output 
packets  in  an  identifier-free  link  layer.  The  primary  disadvantage  of  these  existing  tech¬ 
niques  is  that  they  must  add  significant  overhead  to  ensure  that  all  side-channels  are  hidden 
(e.g.,  by  padding  all  packets  to  the  maximum  packet  length).  We  discuss  these  trade-offs 
and  the  circumstances  under  which  such  overhead  might  be  needed  in  Section  3.6. 


3.2.2  Security  Requirements 

We  want  to  be  able  to  deliver  a  message  from  AtoB  without  identifiers,  but  still  ensure 
that  B  can  verify  it  was  sent  by  A.  More  specifically,  consider  a  procedure  F  that  computes 
c  F{A,  B,  p),  where  A  and  B  are  the  identities  of  the  sender  and  recipient,  respectively, 
p  is  the  original  message  payload,  and  c  is  the  result  which  A  transmits.  (Shared  crypto¬ 
graphic  key  state  is  an  additional,  implicit  input  to  F,  but  we  omit  it  here  for  brevity.)  We 
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want  F  to  have  the  following  four  properties.  We  denote  security  properties  in  this  chapter 
using  small  caps. 

Strong  unlinkability.  To  protect  against  tracking  and  profiling  attacks,  a  sequence 
of  packets  should  not  be  linkable.  More  formally,  any  party  other  than  Aor  B  that  receives 
Cl  =  F{A,  B,pi)  and  C2  =  F{A,  5,  P2)  should  not  be  able  to  determine  that  the  sender  or 
receiver  of  ci  or  C2  are  the  same.  In  particular,  this  implies  that  ci  and  C2  must  not  contain 
consistent  identifiers.  We  note  that  some  packet  types,  such  as  discovery  messages,  are  less 
vulnerable  to  short-term  profiling  and  thus  only  need  to  be  unlinkable  at  coarser  timescales 
to  prevent  long-term  tracking.  Consequently,  we  outline  a  relaxed  version  of  this  property 
in  Section  3.3.3  to  efficiently  handle  these  packets. 

Authenticity.  To  restrict  the  discovery  of  services  to  authorized  clients  and  prevent 
spoofing  and  man-in-the-middle  attacks,  recipients  should  be  able  to  verify  a  message’s 
source.  More  formally,  B  should  be  able  to  verify  that  A  was  the  author  of  c  and  that  it 
was  constructed  recently  (to  prevent  replay  attacks). 

Confidentiality.  No  party  other  than  A  or  B  should  be  able  to  determine  the  contents 
of  p.  In  contrast  to  existing  wireless  confidentiality  schemes,  not  even  fields  and  addresses 
in  the  header  should  be  decipherable  by  third  parties. 

Message  integrity.  Finally,  as  with  existing  802. 1 1  security  schemes,  receivers  should 
be  able  to  detect  if  messages  were  tampered  with  by  third  parties.  More  formally,  B  should 
be  able  to  derive  p  from  c  and  verify  that  it  was  not  altered  after  transmission. 

We  give  more  formal  definitions  for  these  properties  in  Section  3.5. 


3.2.3  Challenges 

The  principal  approach  to  concealing  802.1 1  client  identities  has  been  to  use  MAC  address 
pseudonyms  [67,  84].  Pseudonym  proposals  do  not  meet  our  strong  unlinkability  require¬ 
ment  because  all  packets  sent  under  one  pseudonym  are  trivially  linkable.  Moreover,  the 
use  of  pseudonyms  does  not  conceal  other  information  in  headers,  such  as  capabilities, 
that  can  be  used  to  link  packets  together  [127].  Furthermore,  the  proposals  focus  on  data 
delivery  alone,  and  do  not  address  important  network  functions,  such  as  authentication  and 
service  discovery. 

Prior  approaches  are  limited  because  meeting  all  our  security  requirements  while  main¬ 
taining  important  wireless  functionality  is  nontrivial.  Consistent  destination  addresses  al- 
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low  devices  to  quickly  filter  messages  intended  for  others  so  efficient  data  transport  is 
difficult  without  them.  Moreover,  cryptographic  authenticity  is  difficult  to  provide  without 
identifiers.  Message  recipients  typically  need  to  know  which  cryptographic  key  to  use  to 
verify  a  message,  and  it  is  hard  to  tell  the  recipient  which  one  without  explicitly  identi¬ 
fying  it.  Finally,  removing  identifiers  completely  from  the  process  of  service  discovery  is 
hard  because  wireless  clients  and  services  typically  rendezvous  by  broadcasting  an  agreed 
upon  identifier.  A  service  might  be  willing  to  expose  its  identifier  through  announcements 
to  save  potential  clients  from  having  to  expose  it  in  probes.  No  such  straightforward  solu¬ 
tion  exists  to  conceal  both  client  and  service  identities. 


3.2.4  System  Overview 

In  light  of  the  shortcomings  of  existing  solutions,  we  introduce  the  SlyFi  protocol  that 
meets  our  security  requirements  using  two  identity-concealing  mechanisms.  Tryst  and 
Shroud,  while  providing  functionality  similar  to  802.11.  Before  describing  these  mech¬ 
anisms,  we  first  give  an  overview  of  SlyFi  in  this  section. 

The  SlyFi  link  layer  is  designed  to  replace  802. 1 1  for  managed  wireless  connectivity 
between  clients  and  APs.  The  privacy  protecting  mechanisms  of  the  protocol  explicitly 
protect  all  bits  transmitted  by  the  link  layer.  A  client  wishing  to  join  and  send  data  to  a 
SlyFi  network  sends  a  progression  of  messages  similar  to  802.11  (Figure  3.1).  Instead 
of  sending  these  messages  in  the  clear,  they  are  encapsulated  by  the  two  identity-hiding 
mechanisms  we  describe  in  Section  3.3. 

A  client  first  transmits  probes,  encapsulated  by  Tryst,  to  discover  nearby  APs  it  is  au¬ 
thorized  to  use.  A  probe  is  encrypted  such  that:  1)  only  the  client  and  the  networks  named 
in  the  probe  can  learn  the  probe’s  source,  destination,  and  contents,  and  2)  messages  encap¬ 
sulated  for  a  particular  SlyFi  AP  sent  at  different  times  cannot  be  linked  by  their  contents. 
An  AP  that  receives  a  probe  verifies  that  it  was  created  by  an  authorized  user  and  sends 
an  encrypted  reply,  indicating  its  presence  to  that  client.  If  the  client  wishes  to  establish 
a  link  to  the  AP,  it  sends  an  authentication  request,  also  encapsulated  by  Tryst,  containing 
session  information  including  keys  for  subsequent  data  transmission,  which  are  used  to 
bootstrap  Shroud.  Obviously,  SlyFi  APs  cannot  send  clear-text  beacons  if  they  wish  to 
protect  service  identities.  However,  they  may  do  so  if  they  wish  to  announce  themselves 
publicly.  Such  a  public  announcement  could  immediately  be  followed  by  a  confidential 
authentication  request  from  an  interested  client,  and  thus  would  not  compromise  client 
privacy. 

After  a  link  has  been  established  by  an  authentication  response.  Shroud  is  used  to  con- 
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Figure  3.1:  The  SlyFi  protoeol. 


eeal  the  addresses  and  eontents  of  future  messages  delivered  on  the  link.  An  eavesdropper 
ean  not  use  the  eontents  of  any  two  messages  proteeted  by  Shroud  to  link  them  to  the  same 
sender  or  reeeiver. 

Both  Tryst  and  Shroud  essentially  enerypt  the  entire  eontents  of  eaeh  message,  inelud¬ 
ing  addresses  normally  found  in  the  header.  The  essential  differenees  between  them  arise 
due  to  the  different  requirements  of  diseovery,  link  establishment,  and  data  transfer. 
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3.3  Identifier-Free  Mechanisms 


Identifiers  are  used  in  wireless  protocols  for  two  general  functions:  1)  as  a  handle  by 
which  to  discover  a  service  and  establish  a  link  to  it,  and  2)  to  address  packets  on  a  link 
and  allow  unintended  recipients  to  ignore  packets  efficiently.  Tryst  and  Shroud  address 
each  of  these  functions,  respectively.  To  motivate  our  mechanisms,  we  first  describe  two 
straw  man  mechanisms  that  meet  our  security  requirements,  but  are  inefficient.  We  then 
discuss  Tryst  and  Shroud,  which  are  enabled  by  minor  relaxations  of  these  requirements 
or  additional  assumptions  made  possible  by  their  intended  uses.  We  conclude  the  section 
by  discussing  how  SlyFi  can  still  support  other  protocol  functions,  such  as  higher  layer 
binding. 

To  illustrate  each  mechanism  we  consider  the  scenario  when  A  sends  a  message  p  to 
B.  Each  mechanism  consists  of  three  key  elements:  the  bootstrapping  of  cryptographic 
keys  that  the  sender  and  receiver  require  to  compute  the  procedure  F  (described  in  Sec¬ 
tion  3.2.2);  the  construction  of  c  ^  F{A^  B,p)  by  the  sender;  and  the  message  filtering 
by  a  receiver  to  determine  if  c  is  intended  for  him. 


3.3.1  Straw  Man:  Public  Key  Mechanism 

We  first  sketch  public  key,  a  mechanism  based  on  a  protocol  that  Abadi  and  Foumet  [1] 
prove  meet  the  aforementioned  security  requirements. 

Bootstrapping.  This  mechanism  assumes  that  A  and  B  each  have  a  public/private  key 
pair  and  each  have  the  public  keys  of  the  other. 

Construction.  We  sketch  this  mechanism  here,  but  refer  the  reader  to  the  first  protocol 
discussed  in  [1]  for  details.  To  provide  authenticity,  A  digitally  signs  the  statement  s  = 
{A,  B,T}  where  T  is  the  current  time.  A  message  header  is  constructed  as  an  encryption 
of  s  and  the  digital  signature,  using  5’s  public  key.  By  using  a  public  key  encryption 
scheme  that  does  not  reveal  which  key  is  used,  such  as  ElGamal  [24],  identities  of  neither 
sender  nor  intended  recipient  are  revealed.'  In  addition,  this  achieves  strong  unlinkability 
because  the  ElGamal  encryption  scheme  is  randomized  so  each  encrypted  header  appears 
random.  The  payload  can  be  encrypted  via  conventional  means  (e.g.,  as  described  later  in 
Section  3.3.3). 

'in  practice,  we  would  still  use  RSA  for  faster  signatures;  we  just  require  each  party  to  have  both  ElGamal 
and  RSA  key  pairs. 
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Message  filtering.  When  B  receives  a  message,  he  will  attempt  to  decrypt  this  header.  If 
the  decryption  fails  (i.e.,  the  result  does  not  include  the  statement  {j,  5,  T},  for  a  known 
identity  j),  the  message  is  not  intended  for  B  and  can  be  discarded.  If  decryption  succeeds, 
B  then  checks  the  signature  and  the  time  to  verify  that  the  message  was  recently  generated 
by  j  before  accepting  it. 

Although  this  protocol  achieves  the  security  properties  we  desire,  it  is  slow  because  it 
uses  public  key  cryptography.  In  particular,  on  AP  and  consumer  electronics  hardware,  a 
single  private  key  decryption  can  take  over  100  milliseconds — several  orders  of  magnitude 
greater  than  the  time  required  to  transmit  the  message  (see  Section  3.7).  Since  B  must 
attempt  to  decrypt  the  header  for  every  message  he  receives  whether  he  is  the  intended 
recipient  or  not,  he  can  be  backlogged  just  by  processing  ambient  background  traffic.  One 
way  to  avoid  this  overhead  would  be  to  use  a  public  key  protocol  only  for  infrequently 
occurring  messages,  such  as  802.11  probes.  These  messages  can  be  used  to  exchange  a 
symmetric  key  for  future  messages.  One  problem  with  this  approach  is  that  it  still  leaves 
receivers  susceptible  to  denial-of-service  attacks:  anyone  can  broadcast  “junk”  probes  and 
force  receivers  to  become  back-logged  processing  them.  Moreover,  we  find  that  in  practice 
even  non-adversarial  802.11  probe  traffic  can  be  large  enough  to  back  log  receivers  (see 
Figure  3.9). 

3.3.2  Straw  Man:  Symmetric  Key  Mechanism 

Next  we  sketch  symmetric  key,  a  similar  mechanism  based  on  symmetric  keys  that  ad¬ 
dresses  this  pitfall. 

Bootstrapping.  This  mechanism  assumes  that  A  and  B  share  a  symmetric  key. 

Construction.  Using  symmetric  keys  shared  only  between  A  and  B,  we  can  use  a  con¬ 
struction  intuitively  similar  to  public  key.  A  encrypts  the  statement  s  using  symmetric 
encryption  such  as  AES-CBC.  We  can  omit  A  and  B  from  s  since  it  is  implied  by  the  use 
of  their  symmetric  key.  A  then  computes  a  message  authentication  code  (MAC)  over  the 
encrypted  value  so  B  can  verify  its  authenticity.  A  random  initialization  vector  (IV)  is 
used  so  that  the  resulting  cipher  text  and  MAC  appear  random  and  thus  are  unlinkable  to 
any  other  message. 

Message  filtering.  Upon  receipt  of  a  message,  B  verifies  the  MAC  in  the  header  using  the 
same  key  A  used  to  construct  the  message.  If  the  MAC  does  not  verify,  then  this  message 
is  not  for  B  and  he  can  discard  it. 

Of  course,  since  the  message  does  not  indicate  to  B  which  key  was  used  to  generate 


57 


Symbol 

Definition 

/ 

The  length  of  each  Tryst  time  interval. 

T,To,Ti 

Respectively,  the  current  time,  the  time  Tryst  keys  were  boot¬ 
strapped,  and  the  start  of  time  interval  i:  Tq  +  i  ■  I . 

kp 

A  one-time  use  key  for  encrypting  a  payload. 

l,Enc  i,MAC  uaddr 
^AB  )  ^AB  )  ^AB 

Long-term  keys  to  encrypt,  MAC,  and  compute  addresses  for 
Tryst  messages  sent  from  A  to  B. 

uEnc  uMAC  uaddr 
^s:ABi  ^s:AB  i  ^s:AB 

Session  keys  to  encrypt,  MAC,  and  compute  addresses  for  Shroud 
messages  sent  from  A  to  B. 

AESfc  (6) 

Encipher  single  128-bit  block  b  with  key  k  using  the  AES  cipher. 

AES-CTR2fc  (i,  m) 

Encrypt  m  with  symmetric  key  k  and  128  bit  IV  i  using  the  AES 
cipher  in  CTR2  mode  [139]. 

AES-CMACfc  (m) 

Construct  128-bit  message  authentication  code  (MAC)  of  m  with 
key  k  using  AES-CMAC  [148]. 

SHA1i28  (m) 

Return  first  128  bits  of  a  cryptographic  hash  of  m. 

Table  3.2:  Cryptographic  terminology  used  in  Section  3.3.3-Section  3.4.  All  keys  are  128 
bits. 


the  MAC — indeed  it  cannot,  or  it  will  no  longer  be  unlinkable — and  B  has  a  symmetric 
key  for  each  client  from  whom  he  can  receive  messages,  B  must  try  all  these  keys  to  verify 
the  MAC.  There  is  locality  when  keys  are  used  (e.g.,  A  may  know  that  he  expects  a  reply 
from  B  after  sending  a  message  to  him)  so  we  can  sort  keys  in  most-recently-used  order, 
but,  for  messages  not  intended  for  B,  he  must  try  all  keys  before  discarding  them.  Thus, 
filtering  is  inefficient  for  clients  or  APs  that  have  many  keys. 


3.3.3  Discovery  and  Binding:  Tryst 

We  now  describe  Tryst,  the  mechanism  we  use  for  transmitting  discovery  and  binding 
messages  such  as  802.11  probes  and  authentication  messages.  Tryst  builds  upon  the  sym¬ 
metric  key  straw  man,  but  leverages  the  following  properties  of  these  messages  in  order 
to  enable  efficient  message  processing: 
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s  = 

AES^b^c  (kp)} 

mac  = 

AES-CMAC.  MAC  (s) 

etext  = 

AES-CTR2fe^,  (0128, p) 

emac  = 

AES-CMACfcp2  (etefct) 

32  bytes 

16  bytes 

variable 

16  bytes 

Figure  3.2:  Tryst  packet  format. 


Infrequent  Communication.  Individual  devices  send  discovery  and  binding 
messages  infrequently.  For  example,  802. 1 1  clients  send  probes  only  when 
they  are  searching  for  an  AP  and  send  authentication  messages  only  at  the 
beginning  of  a  session  or  when  roaming  between  APs. 

Narrow  Interface.  Unlike  data  packets,  which  can  contain  arbitrary  contents, 
there  are  very  few  different  messages  that  are  used  for  discovery  and  bind¬ 
ing.  Thus,  it  is  unlikely  that  their  evolution  at  short  time  scales  exposes  many 
sensitive  side  channels  of  information  when  individual  messages  are  not  de¬ 
cipherable.  It  is  only  the  ability  to  link  these  messages  together  at  long  time 
scales  (e.g.,  hours  or  days)  that  threatens  location  privacy. 


Based  on  these  two  observations,  we  define  a  relaxed  version  of  the  strong  unlinkability 
property: 

Long-term  unlinkability.  Let  t{m)  be  the  time  a  message  m  was  generated.  Any 
party  other  than  Aox  B  that  receives  ci  =  F{A,  B,  pi)  and  C2  =  F{A,  B,  P2)  should  not  be 
able  to  determine  that  the  sender  or  receiver  of  ci  or  C2  were  the  same  if  \t{c2)  —  t(ci)|  >  I, 
for  some  time  interval  I.  In  practice,  /  would  be  several  minutes  and  may  be  different  for 
each  client- service  relationship. 

Tryst  achieves  this  relaxed  form  of  unlinkability,  which  is  sufficient  for  discovery  and 
binding  messages  because  very  few  are  likely  to  be  generated  during  any  given  interval  /. 

Even  if  an  adversary  is  able  to  force  multiple  discovery  messages  to  be  generated  during 
one  interval,  e.g.,  by  jamming  the  channel  to  force  all  clients  to  reassociate,  the  ability  to 
link  them  together  is  unlikely  to  be  threatening. 

For  clarity,  we  list  the  cryptographic  terminology  we  use  in  the  subsequent  description 
in  Table  3.2. 

Bootstrapping.  Similar  to  symmetric  key,  A  and  B  each  have  symmetric  keys  k^^^ ,  k^^'^ 

for  constructing  messages  from  AtoB  (and  another  set  of  keys  for  B  to  A).  They  also 
remember  the  time  they  exchanged  these  keys  as  Tq. 
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Temporary  unlinkable  addresses.  A  client  A  and  a  service  B  that  share  a  symmetric 
key  can  independently  compute  the  same  sequence  of  unlinkable  addresses  and  thus  will 
at  any  given  time  know  which  address  to  use  to  send  messages  to  the  other.  Specifically: 

addr\^  =  AES^ad^r  (i) ,  where  i  =  [(T  —  To)//J 

In  other  words,  addr\^  is  a  function  of  the  ith.  time  interval  after  key  negotiation.  The 
crucial  property  we  leverage  is  that,  without  knowledge  of  /c,  it  is  intractable  for  an  adver¬ 
sary  to  distinguish  a  set  of  address  values  {AES^  (ji) ,  AES^  (j^) ,  •  •  • ,  AES^  (jn)}  from 
random  bits.^  As  a  consequence,  for  any  two  values  AES^^  (A)  and  AES^j  (*2)  where 
ii  7^  12,  it  is  intractable  for  a  third  party  to  determine  whether  ki  =  k2,  even  if  A  and  12 
are  known.  Thus,  these  addresses  are  unlinkable  without  knowledge  of 

In  practice,  B  computes  addr\^  once  at  time  Ti  =  TQ  +  i-L  B  maintains  a  hash  table 
containing  the  addresses  for  messages  he  might  receive.  At  time  Tj,  he  clears  the  table  and 
inserts  the  key-value  pair  (addr*^,  j)  for  each  identity  j  he  has  keys  for,  so  that  he  can 
anticipate  messages  sent  with  these  addresses  and  determine  that  he  should  use  j’s  keys  to 
process  them.  When  A  wants  to  send  a  message  to  B  at  time  T,  he  also  computes  addr\^. 
Section  3.4.1  discusses  how  we  deal  with  clock  skew. 

Construction.  Tryst(A,  B,p)  is  computed  as  follows  (Figure  3.2): 

1.  Generate  a  random  key  kp. 

2.  header  ^  {s,mac},  where: 

s  =  {addr\j^,  AES (kp)}, 
mac  =  AES-CMAC;i.MAc  (s) . 

header  proves  to  B  that  A  is  the  sender  and  B  the  receiver  because  only  A  and 
B  have  and  k^^^ .  Moreover,  it  proves  to  B  that  it  was  constructed  near  the 

current  time  T  because  addr\^  is  a  cryptographic  function  of  T.  This  provides 
authenticity. 

To  third  parties,  mac  appears  to  be  random  because  it  is  computed  over  the  encryp¬ 
tion  of  random  key  kp,  so  neither  it  nor  the  encipherment  of  kp  can  link  it  to  other 
messages.  addr\^  is  sent  “in  the  clear”  and  will  be  used  in  all  messages  sent  dur¬ 
ing  time  interval  Tj,  but  addA}^  and  addAj^  for  any  il  7^  i2  are  unlinkable,  thus 
providing  long-term  unlinkability. 

^We  make  the  standard  assumptions  that  AES  is  a  good  pseudorandom  permutation  and  that  n  <  2®^. 
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3.  ctext  ^  {etext,  emac},  where: 

etext  =  AES-CTR2fcpj  , 

emac  =  AES-CMACfc^j  (etext) . 

kpi  and  kp2  are  pseudo-random  keys  derived  from  kp  (e.g.,  kpi  =  kp  and  kp2  = 
SHA1 128  (kp)).  ctext  is  an  eneryption  of  the  payload  p  along  with  a  MAC  whieh, 
given  kp,  verifies  that  the  payload  was  not  altered  during  transmission.  We  derive 
two  keys  from  kp  so  that  different  keys  are  used  for  eneryption  and  MAC.  Sinee  kp 
is  random,  ctext  will  be  different  from  previous  messages  even  when  an  identieal 
payload  p  was  sent  before.  (Note  that  sinee  key  kp  is  only  used  onee,  the  IV  0^^®  is 
still  a  nonee  for  that  key’s  “session.”) 

4.  c  <—  {header,  ctext}. 

A  more  formal  demonstration  of  Tryst’s  seeurity  properties  ean  be  found  in  Seetion  3.5. 

The  overhead  (64-80  bytes  per  message)  is  aeeeptable  sinee  diseovery  and  binding 
messages  are  sent  infrequently. 

Message  filtering.  Upon  reeeption  of  sueh  a  message,  B  simply  eheeks  his  hash  table  to 
determine  if  he  has  an  address  addr\^.  If  he  does,  it  will  be  assoeiated  with  the  keys  for 
A,  whieh  ean  be  used  to  verify  and  deerypt  the  header.  If  not,  he  ean  diseard  the  message. 
Onee  header  is  deerypted,  he  obtains  kp,  whieh  ean  be  used  to  deerypt  and  verify  ctext 
to  retrieve  the  original  p.  In  eontrast  to  the  straw  man  meehanisms,  this  protoeol  enables 
deviees  to  diseard  messages  not  intended  for  them  effieiently,  using  hash  table  lookups 
instead  of  eostly  eryptographie  operations. 

3.3.4  Data  Transport:  Shroud 

Tryst  is  insuffieient  for  identifier-free  data  transport  beeause  data  messages  are  neither  in¬ 
frequent  nor  do  they  have  a  narrow  interfaee.  Thus,  to  defend  against  side-ehannel  analy¬ 
sis,  we  want  strong  unlinkability  rather  than  just  long-term  unlinkability.  Shroud  maintains 
this  property  effieiently  by  leveraging  a  key  assumption  about  data  transport: 

Connected  Communication.  Whereas  diseovery  messages  are  often  sent  at 
times  when  they  will  not  be  reeeived,  data  messages  are  only  sent  after  a  link 
has  been  established.  Thus,  a  sender  and  reeeiver  ean  assume  that,  barring 
message  loss,  their  messages  will  be  reeeived  by  their  intended  reeipient. 
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In  effect,  this  assumption  enables  Shroud  to  compute  a  sequence  of  unlinkable  addresses 
on  a  per  packet  basis,  as  we  will  describe  shortly. 

Bootstrapping.  We  bootstrap  Shroud  with  random  session  keys  k^^§  for 

messages  from  Aio  B.  These  keys  are  exchanged  in  SlyFi’s  authentication  messages  (see 
Figure  3.1)  and  thus  are  protected  by  Tryst. 

Per-packet  unlinkable  addresses.  The  only  design  choice  in  Tryst  that  sacrifices  strong 
unlinkability  is  the  use  of  the  same  addr\^  for  all  packets  during  time  interval  i.  Thus, 
we  can  essentially  use  Tryst,  provided  that  we  can  compute  addresses  addr\^  per  packet 
rather  than  per  time  interval.  To  do  this  in  Shroud,  addr\^  is  computed  as  a  function  of 
the  fth  transmission  since  link  establishment: 

addr\^  =  AES;.a<Mr  (f ) ,  where  i  =  transmission  number 

Since  a  connection  has  been  established,  B  will  receive  every  packet  sent  by  A  on  this  link 
barring  message  loss,  and,  hence,  B  only  needs  to  compute  address  i  +  1  after  the  receipt 
of  message  f;  i.e.,  B  computes  the  address  he  expects  in  the  next  message. 

Of  course,  message  loss  in  wireless  networks  is  common,  so  we  would  like  to  be  able 
to  tolerate  the  loss  of  w  consecutive  losses  for  some  w.  Thus,  on  receipt  of  message  i,  a 
receiver  computes  the  (f  +  l)th  to  (f  +  tu)th  addresses  and  inserts  them  all  into  its  hash 
table  (removing  all  addresses  j  <  i).  Note  that,  except  for  the  first  message  received  (e.g., 
the  association  request  or  reply  in  SlyFi),  which  requires  the  computation  of  w  addresses, 
only  one  additional  address  needs  to  be  computed  for  each  subsequent  packet  sent  to  B, 
unless  there  are  message  losses;  B  performs  no  address  computation  for  packets  destined 
for  other  devices  that  it  overhears.  Section  3.4.2  discusses  how  we  choose  w  and  perform 
link  layer  retransmissions. 

To  avoid  the  overhead  of  storing  these  addresses,  an  alternative  design  would  be  to  use 
the  same  address  until  a  message  transmission  is  successful.  However,  this  approach  is 
problematic  when  each  message  is  only  transmitted  a  small  number  of  times  before  giving 
up,  as  in  802.11.  In  these  circumstances,  the  same  address  can  be  used  on  many  distinct 
consecutive  packets,  which  violates  strong  unlinkability.  This  is  particularly  problematic 
because  an  adversary  that  actively  jams  a  channel  can  cause  the  loss  of  packets,  forcing  a 
sender  to  use  the  same  address  for  many  consecutive  packets. 

Construction.  With  per-packet  unlinkable  addresses,  we  could  use  the  Tryst  construction 
and  achieve  the  desired  security  properties  and  filter  packets  efficiently.  However,  we  can 
make  additional  optimizations.  Shroud(A,  B,p)  is  computed  as  follows  (Figure  3.3): 

1.  header  ^  addr\^. 


62 


header  =  addr'^^^ 

etext  =  AES-CTR2^En.c  (header,  p) 

emac  =  AES-CMAC^mac  (header,  etext) 

16  bytes 

variable 

16  bytes 

Figure  3.3:  Shroud  packet  format. 


Unlike  in  Tryst,  no  Shroud  address  will  ever  appear  in  two  different  messages;  thus 
no  one  can  successfully  record  and  replay  them.  As  a  consequence,  addr\^  itself 
proves  to  B  that  A  sent  the  message  to  B  and  that  it  was  message  transmission  i, 
which  B  expects.  This  provides  authenticity.  Each  message  will  have  a  different 
address  and  addresses  are  strongly  unlinkable. 

2.  ctext  ^  {etext,  emac},  where: 

etext  =  AES-CTR2^Bn,^  {header,  p) , 
emac  =  AES-CMAC^mac  {header,  etext) . 

In  Tryst,  we  use  a  random  key  to  perform  the  encryption  to  ensure  that  the  encrypted 
payload  and  MAC  are  unlinkable  to  previous  messages  even  if  their  contents  are  the 
same.  Since  each  Shroud  address  is  different  and  is  used  only  once,  header  effec¬ 
tively  serves  as  a  nonce  that  we  can  use  as  an  IV  to  the  encryption  of  the  payload. 
This  ensures  that  etext  is  unlinkable  to  previous  messages  even  if  their  contents 
are  the  same  and  we  use  the  same  key  for  encryption.  Similarly,  we  include 
header  in  the  computation  of  emac  to  ensure  that  it  is  unlinkable  to  previous  mes¬ 
sages  even  if  p  is  null. 

3.  c  ^  {header,  etext}. 

A  more  formal  demonstration  of  Shroud’s  security  properties  can  be  found  in  Section  3.5. 

We  note  that  addr\^  implies  the  three  Ethernet  addresses  in  p  so  they  can  be  removed, 
saving  18  bytes.  Therefore,  Shroud’s  additional  16  bytes  of  overhead  can,  in  practice,  be 
a  net  savings  of  2  bytes. 

Message  filtering.  As  in  Tryst,  B  determines  whether  a  message  is  for  him  by  looking 
up  addr\^  in  the  hash  table  containing  his  precomputed  addresses.  In  fact,  since  the 
address  is  located  in  the  same  position  in  both  Tryst  and  Shroud  packets,  there  is  no  need 
to  distinguish  the  two  message  types  and  a  single  hash  table  can  be  shared  by  both.  The 
value  associated  with  each  address  key  in  the  hash  table  will  indicate  whether  it  should  be 
demultiplexed  to  Tryst  or  Shroud. 
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3.3.5  Other  Protocol  Functions 


Tryst  and  Shroud  make  the  crucial  elements  of  a  link  layer  protocol — discovery,  binding, 
and  data  transport — identifier-free,  but  other  protocol  functions  must  be  supported  as  well. 
In  this  section,  we  explain  how  SlyFi  can  support  these  functions  without  introducing 
identifiers. 

Broadcast.  Shroud  supports  identifier-free  broadcast  transmissions  in  managed  mode. 
Broadcasted  frames  are  encrypted  with  a  key  and  sequence  number  that  are  shared  by  the 
AP  and  all  clients  on  the  local  network.  As  in  802.irs  managed  mode,  a  client  forwards 
frames  to  the  AP  that  it  wishes  the  AP  to  broadcast.  In  Shroud,  the  transmission  to  the 
AP  is  protected  by  the  per-client  shared  key  used  for  unicast  transmissions.  (A  client 
optionally  may  divulge  his  identity  to  all  associated  stations  by  including  his  source  ad¬ 
dress.)  Upon  reception  at  the  AP,  the  frame  is  decrypted  and  then  re-encrypted  with  the 
shared  broadcast  key.  The  shared  key  and  current  sequence  number  are  managed  by  the 
AP  and  conveyed  to  each  of  its  clients  during  association.  Although  SlyFi  currently  does 
not  support  broadcast  key  revocation,  we  believe  we  can  apply  a  scheme  similar  to  that  of 
802.111  [80];  this  is  is  a  topic  of  future  work. 

Binding  to  higher  layer  identifiers.  There  is  often  a  need  to  bind  higher  layer  names  to 
link  layer  addresses.  For  example,  ARP  binds  Ethernet  addresses  to  IP  addresses.  Obvi¬ 
ously,  we  do  not  want  to  have  to  re-establish  this  binding  for  every  Shroud  address  change. 
Instead,  we  have  the  AP  negotiate  with  each  client  a  pseudonym  address  that  remains  con¬ 
sistent  for  that  session,  but  that  is  not  sent  in  actual  messages.  The  client  informs  the  AP 
of  its  IP  to  pseudonym  binding  whenever  its  IP  address  changes.  Thus,  the  AP  can  answer 
all  ARPs. 

Announcement.  Beacons  are  broadcasted  in  the  clear  to  announce  an  802. 1 1  AP.  While 
SlyFi  does  not  prevent  beacons,  an  AP  that  wants  to  hide  its  presence  obviously  cannot 
use  them.  To  discover  APs  in  SlyFi,  a  client  must  have  the  necessary  Tryst  keys  to  probe 
for  it.  We  do  not  believe  this  is  a  hindrance,  since  existing  secure  802. 1 1  networks  already 
require  secure  out-of-band  channels  to  exchange  keys  before  association. 


Time  synchronization.  Beacons  are  also  used  to  convey  timestamps  so  that  clients  and 
APs  can  synchronize  their  clocks.  With  synchronized  clocks,  clients  need  only  turn  on 
their  radios  at  designated  times  to  receive  packets  when  operating  in  low  power  modes. 
Since  only  clients  on  the  local  network  need  to  synchronize  their  clocks,  this  information 
can  be  encrypted  using  the  broadcast  encryption  key  described  above. 
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Roaming.  Clients  sometimes  use  probes  or  beacons  after  association  to  search  for  better 
APs  to  roam  to.  Using  Tryst  to  send  these  probes  might  be  expensive  if  a  client  sends 
them  frequently.  However,  these  APs  are  usually  in  the  same  administrative  domain  and 
thus  could  share  a  broadcast  key,  which  could  be  used  to  encrypt  these  messages  instead  of 
using  Tryst.  In  addition.  Shroud  session  state  could  be  migrated  between  APs  in  advance, 
similar  to  how  WPA  pre-authentication  is  performed. 

Coexistence.  Our  implementation  of  SlyFi  can  coexist  with  normal  802. 1 1  devices  be¬ 
cause  we  encapsulate  SlyFi  messages  in  management  frames  that  normal  802. 1 1  devices 
ignore  (see  Section  3.4.3).  The  medium  access  protocol  is  unchanged.^  Thus,  SlyFi  can 
be  deployed  incrementally.  In  a  mixed  environment,  a  SlyFi-enabled  client  can  first  search 
for  a  SlyFi-enabled  AP  using  Tryst  probes.  If  no  such  AP  is  found,  then  a  client  willing  to 
fail-back  to  a  normal  802. 1 1  AP  can  listen  for  beacons  and  associate  normally. 


3.4  Implementation  Details 

This  section  discusses  practical  considerations  involved  in  implementing  Tryst,  Shroud, 
and  our  SlyFi  prototype. 


3.4.1  Tryst:  Practical  Considerations 

Clock  skew.  In  practice  A  and  B  will  not  have  perfectly  synchronized  clocks.  To  allow 
for  clock  skew  uptok-I  between  devices,  B  should  anticipate  the  addresses  that  may  be 
used  for  any  messages  sent  in  the  time  range  [Ti_k,  Tj+fc]  at  time  Tj.  Thus,  he  also  inserts 
(or  keeps)  . . . ,  into  the  table  for  all  identities  j  for  which  he 

has  keys.  Note  that  messages  sent  by  A  will  still  only  use  the  address  addA^^  for  one  time 
interval  of  length  I.  B  will  simply  accept  messages  with  that  address  for  longer. 

Scoped  broadcast.  A  client  may  want  to  send  the  same  discovery  message  to  multi¬ 
ple  services  (e.g.,  to  discover  any  one  of  them).  To  do  this,  A  constructs  one  header 
for  each  intended  recipient,  but  includes  the  same  kp  in  each  header;  e.g.,  he  sends 
{headerl, . . . ,  headerN,  ctext}.  Hence,  any  party  that  can  interpret  any  one  header  can 
obtain  kp  and  decrypt  the  payload.  However,  each  party  can  only  interpret  the  header 
intended  for  them,  so  the  identities  of  the  other  parties  remain  obscured.  One  problem 

^  We  do  not  yet  support  RTS/CTS  because  our  software  implementation  is  not  fast  enough  to  perform 
filtering  at  the  timescale  required,  but  we  note  that  RTS/CTS  is  rarely  used  in  actual  managed  networks. 
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with  this  approach  is  that  a  legitamite  receiver  can  not  tell  where  ctext  begins  in  the  mes¬ 
sage.  To  discover  it,  he  could  try  verifying  cmac  starting  from  every  block  offset  after  his 
header.  Alternatively,  we  could  encrypt  N  within  each  header  itself  (at  the  cost  of  another 
16  byte  block  per  header). 

Forward  security.  One  concern  is  that  is  stored  for  a  long  time  and  if  it  is  compro¬ 
mised,  an  adversary  could  compute  the  addresses  of  all  messages  that  A  ever  sent  to  B. 
We  mitigate  this  risk  by  computing  a  new  key  each  day  using  a  forward-secure  pseudo¬ 
random  bit  generator  [22];  i.e.,  the  key  for  day  j:  ^  SHA1 123  j  •  Both 

A  and  B  discard  the  old  key  and  use  the  new  key  for  computing  addresses.  The  address 
computation  remains  the  same,  but  an  adversary  that  obtains  would  only  be  able 

to  compute  addresses  for  days  j  and  after. 

Public  services  .  Mutual  confidentiality  is  not  always  required.  For  example,  802. 1 1  APs 
at  hotspots  are  immobile  and  public  and  do  not  need  to  hide  their  presense  to  eavesdroppers — 
indeed,  they  want  to  be  discovered  so  that  clients  will  pay  to  use  them.  Although  Tryst 
can  still  be  used  in  these  circumstances,  it  will  hinder  the  discovery  of  public  services  that 
clients  do  not  yet  know  about;  clients  would  have  to  discover  the  existence  of  these  APs 
through  out-of-band  means  and  exchange  a  key  (e.g.,  by  asking  the  hotstop  owner).  Futher- 
more,  large  networks  of  public  hotspots,  such  as  AT&T  Wi-Fi  and  T-Mobile  Hotspots,  may 
have  hundreds  of  thousands  or  millions  of  registered  clients.  Using  Tryst,  they  would  need 
to  compute  and  store  new  addresses  for  each  of  these  clients  every  time  interval  T,  which 
may  be  burdensome. 

When  the  service  does  not  need  to  hide  its  presence  during  discovery,  it  can,  instead, 
use  a  variant  that  publically  authenticates  the  service  and  only  conceals  the  identity  of 
the  client.  For  example,  JFKi  [7],  a  protocol  originally  designed  for  IPSec  key  exchange, 
can  be  used  in  place  of  Tryst  to  establish  a  session  key  for  Shroud.  The  basic  idea  is 
that,  because  the  service  is  public,  it  can  announce  and  authenticate  its  identity  using  a 
certificate  chain  (as  in  SSL).  With  judicious  use  of  nonces,  a  client  can  use  the  standard 
Diffie-Hellman  protocol  to  exchange  a  key  with  the  service  without  revealing  its  identity 
to  anyone  except  the  service. 


3.4.2  Shroud:  Practical  Considerations 

Choosing  w.  w  determines  the  number  of  consecutive  packet  losses  Shroud  can  endure. 
In  practice,  burst  losses  of  more  than  50  packets  are  extremely  rare  on  usable  links  [136] 
so  we  use  tc  =  50.  A  larger  burst  loss  will  result  in  a  higher  level  timeout  and  require  re- 
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establishing  the  link.  The  overhead  required  to  maintain  these  addresses  is  not  prohibitive; 
even  a  heavily  loaded  AP  with  256  clients  (the  max  supported  by  the  standard  MadWifi 
driver  [110])  requires  only  1MB.  Most  clients,  which  only  have  one  association  at  a  time, 
could  easily  check  message  addresses  in  hardware  with  no  more  delay  or  energy  than 
existing  NICs.  We  show  in  Section  3.7.4  that  even  software  filtering  incurs  little  overhead. 

Acknowledgments.  Every  unicast  802. 1 1  data  packet  is  acknowledged  by  the  receiver  to 
manage  message  loss.  In  principle,  link-layer  acknowledgments  can  simply  acknowledge 
the  address  of  the  received  Shroud  packet,  since  the  sender  knows  the  last  address  used. 
However,  our  current  implementation  is  in  software  and  thus  is  unable  to  send  this  ack 
within  the  16  microseconds  allotted  to  it.  Therefore,  we  currently  use  software  acks  that 
selectively  acknowledge  cumulative  windows  of  data  packets.  Each  acknowledgment  and 
message  retry  is  processed  anew  by  Shroud. 


3.4.3  Prototype  Implementation 

We  implemented  SlyEi  in  C-t-i-  using  the  Click  Modular  Router  [94],  incorporating  Tryst 
and  Shroud  with  its  existing  802.1 1  implementation  (which  is  by  the  authors  of  Roofnet  [140]). 
Since  existing  802. 1 1  NICs  will  not  send  frames  without  proper  802. 1 1  headers,  each  Tryst 
or  Shroud  message  is  encapsulated  in  an  “anonymous”  802.11  header,  i.e.,  one  with  con¬ 
stant  fields  and  addresses.  NICs  are  placed  in  promiscuous  mode  so  that  they  receive 
all  these  frames  and  perform  filtering  in  software.  We  use  the  cryptographic  routines  in 
libgcrypt  [106]  and  ran  our  software  as  a  Einux  kernel  module. 

We  note  that  the  following  evaluation  section  uses  a  SlyEi  implementation  that  is 
slightly  different  from  the  protocol  we  described  in  the  previous  sections.  This  variant, 
described  in  [63],  uses  CBC  mode  rather  than  CTR2  mode  to  encrypt  message  payloads 
(see  Table  3.2).  CTR2  mode  is  uses  the  same  number  of  AES  operations,  has  less  message 
overhead,  can  be  computed  in  parallel,  and  is  provably  secure.  Therefore,  the  results  we 
present  for  SlyEi  in  the  following  section  are  (slightly)  conservative. 


3.5  Formal  Security  Analysis 

In  this  section,  we  define  and  demonstrate  SlyEi’s  confidentiality  and  unlinkability  prop¬ 
erties  (outlined  in  Section  3.2.2)  with  more  formal  rigor.  We  omit  a  more  detailed  analysis 
of  the  authenticity  and  message  integrity  properties  because  both  Tryst  and  Shroud  make 
standard  usage  of  CMAC  to  authenticate  and  maintain  the  integrity  of  the  message  payload 
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(etext),  so  they  are  directly  dependent  on  the  security  of  CMAC  [83].  More  specifically, 
we  show  in  this  section  that  the  output  of  Tryst’s  and  Shroud’s  encapsulation  functions  are 
indistinguishable  from  random  bits  to  a  computationally  bounded  adversary.  This  property 
implies  confidentiality  and  unlinkability. 


3.5.1  Preliminaries 

We  use  the  standard  definitions  of  security  properties  and  proof  model  pioneered  in  the 
work  of  Bellare  and  Rogaway  [20,  23,  139,  25].  The  reader  is  referred  to  this  body  of 
work  for  in-depth  coverage  of  these  definitions  and  the  security  proof  framework.  We  also 
list  the  definitions  relevant  to  our  security  analysis  in  this  section. 

We  use  the  standard  definitions  of  random  functions,  permutations,  random  bits,  and 
nonce-based  encryption  schemes,  which  are  defined  as  follows  [2,  32,  139]: 

•  Rand(P,  TZ)  is  the  family  of  pseudorandom  functions  from  V  ^IZ. 

•  Perm(T’,  IZ)  is  the  family  of  permutations  from  V  IZ. 

•  $”  is  a  sequence  of  n  random  bits. 

•  n(n)  =  {IC,S,V)  is  a  nonce-based  encryption  scheme  where  K.  =  {0, 1}*^  is  the 
set  of  keys,  S  :  JC  x  J\f  x  Ai  ^  C  is  the  set  of  encryption  functions,  V  :  K,  x 
U  X  C  ^  Aiis  the  set  of  decryption  functions,  Ai  is  the  set  of  plaintexts,  C  is  the 
set  of  ciphertexts,  and  M  =  {0, 1}”  is  the  set  of  all  nonces.  We  call  n  the  security 
parameter  of  the  encryption  scheme.  Each  member  of  n(n)  is  distinguished  by  a 
key  in  K.. 

•  E  ^  S  denotes  the  uniformly  random  selection  of  an  element  E  from  the  set  S. 


Encapsulation  functions.  We  define  an  encapsulation  function,  a  generalization  an  en¬ 
cryption  function,  as  follows:  E{n,  /,  k)  is  a  family  of  encapsulation  functions  Vi  XV2  x 
...  X  Vi  ^  TZ  if  k  inputs  Va, . . . ,  Vik  =  {0, 1}"^,  1  <  k  <  1.  We  call  these  inputs  the 
function’s  keys.  Each  member  of  E  is  distinguished  by  fixing  its  keys.  We  call  k  ■  n  the 
security  parameter  of  the  encapsulation  function  family.  Eor  brevity,  we  often  use  E  to 
refer  to  E{n,  I,  k)  when  the  parameters  are  clear  from  context.  Note  that  a  nonce-based 
encryption  function  family  S  is  an  instance  of  E{n,  3, 1). 
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For  brevity,  we  use  f  ^  F  to  denote  where  Ki  ^  Vn, . . .  ,Kj.  ^  Vi^  and 

T>ii, . . . ,  Vik  are  F’s  keys.  In  other  words,  /  is  a  member  of  F  that  is  selected  by  randomly 
selecting  each  of  F’s  keys. 

Security  properties.  We  are  interested  in  showing  that  the  Tryst  and  Shroud  encapsula¬ 
tion  functions  in  SlyFi  are  ENCAP-IND$-CPA-secure,  a  property  that  we  define  below. 
Intuitively,  a  function  that  is  ENCAP-IND$-CPA-secure  means  that  its  outputs  are  indis¬ 
tinguishable  from  random  sequence  of  bits  of  the  same  lengths  (i.e.,  for  tryst), 

given  that  the  adversary  is  computationally  bounded  but  can  choose  all  the  inputs  and  ob¬ 
serve  all  the  outputs.  ENCAP-IND$-CPA  is  practically  identical  to  IND$-CPA  (indistin- 
guishability  from  random  bits  under  a  chosen  plaintext  attack),  another  common  property 
in  the  literature  that  we  define  below.  The  only  difference  is  that  ENCAP-IND$-CPA 
refers  to  an  arbitrary  encapsulation  function  whereas  IND$-CPA  refers  to  an  encryption 
scheme.  We  distinguish  these  two  properties  for  clarity  (Lemma  6  shows  that  IND$-CPA 
implies  ENCAP-IND$-CPA  for  the  encryption  function).  These  properties  imply  the 
standard  notions  of  confidentiality  and  key-indistinguishability  [139]  (key-indistinguishability 
is  synonymous  with  unlinkability  —  an  adversary  can  not  link  a  message  to  a  particular 
encryption  key). 

Adversaries,  oracles,  and  security  games.  In  the  following  definitions,  we  consider  the 
following  standard  experiment  or  “game.”  A  chosen  plaintext  probabilistic  polynomial 
time  adversary  A  is  given  access  to  one  of  two  oracle  functions  (e.g.,  one  that  is  our 
encapsulation  function  or  one  that  returns  truly  random  bits).  We  use  )  to  denote 

that  the  adversary  A  is  given  the  oracle  oracle(-).  The  adversary  does  not  know  which 
oracle  he  was  given  but  it  can  make  q  queries  to  it  and  spend  t  time  computing.  In  addition, 
the  total  size  of  all  queries  submitted  may  not  exceed  a.  {t,  q,  a)  are  the  resource  bounds  on 
the  adversary.  We  use  only  (f,  a)  to  describe  the  resource  bounds  of  adversaries  attacking 
block  ciphers,  which  have  fixed  sized  inputs  and  outputs;  we  omit  the  number  of  queries  q 
since  q  =  0{a). 

The  adversary’s  goal  is  to  to  determine  which  oracle  it  was  given;  it  returns  0  if  it  thinks 
it  is  the  first,  and  1  if  it  thinks  it  is  the  second.  We  want  to  minimize  an  adversary  A’s 
advantage  Adv^™*’(A),  a  measure  of  how  likely  that  it  guesses  correctly  when  attacking 
security  property  prop  of  encryption  scheme  F.  We  use  the  notation  Adv^™'’(t,  q,  a)  to 
denote  the  maximal  advantage  of  all  adversaries  that  spend  up  to  t  time  computing  and 
make  q  queries  with  total  size  a.  We  define  an  adversary’s  advantage  more  formally  below. 

This  game  corresponds  to  the  scenario  where  an  eavesdropper  observes  all  packets  sent 
and  wants  to  determine  whether  they  are  random  bits  or  actual  Tryst  and  Shroud  packets. 
This  is  a  strictly  easier  problem  than  trying  to  decrypt  them  or  to  link  them  to  a  particular 
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key  (i.e.,  sender  or  receiver).  Therefore,  if  an  adversary  can  not  distinguish,  it  also  can  not 
decrypt  or  link  packets.  Moreover,  we  consider  a  strong  adversary  that  is  able  to  determine 
the  inputs  (e.g.,  plaintext  payloads)  of  all  packets  sent.  Therefore,  this  game  represents  a 
strictly  more  powerful  adversary  than  one  would  probably  encounter  in  practice.  The 
purpose  of  considering  such  an  adversary  is  to  show  that  our  schemes  are  secure  even  with 
minimal  assumptions  about  the  adversary. 

Useful  definitions.  We  enumerate  relevant  security  definitions  and  lemmas  below. 


Definition  3.5.1  (ENCAP  -IND$-CPA)  Let  F{n,  m,  k)  be  a  family  of  encapsulation  func¬ 
tions  Vi  X  V2  X  . . .  X  Vi  ^  TZ,  and  let  Abe  a  an  algorithm  that  takes  an  oracle  and 
returns  a  bit.  Define 


AdvENCAP-IND$-CPA 

F 


(A)  =  Pr  1/ ^  F  :  =  1 

Pr  1/  ^  F  :  =  l 


We  say  an  encapsulation  function  family  F(n,  I,  k)  with  k  keys  is  ENCAP-IND$-CPA- 
secure  if  <  e{k  ■  n)  for  all  adversaries  A,  where  e{k  ■  n)  is  negli¬ 

gible."^ 


Definition  3.5.2  (IND$-CPA)  [2,  139]  Let  n(n)  =  (/C,  S,  V)  be  a  nonce-based  encryp¬ 
tion  scheme,  n  be  the  security  parameter,  and  let  Abe  a  nonce-respecting  chosen  plaintext 
attack  adversary.  A  nonce-respecting  adversary  is  one  that  does  not  submit  any  query 
{N,  ■)  after  submitting  a  query  {N,  M),  N  E  J\f.  Define 


Adv™-^P"^(A)  =  Ft  k^lC:  A^^^-\n)  =  1 

Pr 


kFlC:  =  1 


We  say  an  encryption  scheme  family  n(n)  is  IND$-CPA-secure  if  Adv™°*  “"^^(A)  < 
e(n)  for  all  adversaries  A,  where  e(n)  is  negligible. 

function  e(n)  is  negligible  if  for  every  polynomial  P(-)  there  exists  an  N  such  that  for  all  integers 
n  >  N,  e(n)  <  P(n). 
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Definition  3.5.3  fIND$-CPA  ’)  Letn(n)  =  (/C,  S,V)  be  a  nonce-based  encryption  scheme, 
n  be  the  security  parameter,  and  let  Abe  a  random-nonce  chosen  plaintext  attack  adver- 
sary.  A  random-nonce  adversary  is  one  that  selects  N  ^  Af  for  each  query  (iV,  M)  that 
it  submits.  Define 


AJ,/IND$-CPA' 


(^) 


def 


Pr 

Pr 


k^lC:  =  1 


Definition  3.5.4  (prfj  [32]  Let  F  :  V  ^  TZ  be  a  family  of  functions  where  IZ  =  {0, 1}*^ 
for  n>l,  and  let  A  be  an  algorithm  that  takes  an  oracle  and  returns  a  bit.  Then 

AdvP''f(A)  =  Pr[/ ^  F  :  =  1] -Pr[p^  Rand(P>,7^)  ;  =  1] 

Definition  3.5.5  (prpj  [32]  Let  F  :  V  LZ  be  a  family  of  functions  IZ  =  {0,1}” /o?" 
n  >  1,  and  let  A  be  an  algorithm  that  takes  an  oracle  and  returns  a  bit.  Then 

AdvP’^P(A)  =  Pr[/  ^  F  :  A^^'^  =  1]  -  Pr[7r  ^  Perm(P>,  TZ)  :  A^^'^  =  1] 

Lemma  1  (PRF/PRP  Switching)  [32]  Fix  n  >  1.  Let  A  be  an  adversary  that  asks  at  most 
q  queries.  Then 

Pr[7r  ^  Perm(P>,F)  :  =  1]  -  Pr[p  ^  Rand(P>,F)  :  =  1] 

where  F  =  F  =  (0,  !}"■  for  n>l. 


3.5.2  Security  of  Each  Part 

We  first  show  that  each  constituent  part  of  the  Tryst  and  Shroud  encapsulation  functions 
are  ENCAP-IND$-CPA-  or  IND$-CPA-secure.  Note  that  each  part  itself  is  also  an  en¬ 
capsulation  function.  In  the  next  section,  we  demonstrate  how  to  describe  the  security  of 
the  combination  of  these  parts. 

Security  of  addr.  Define  J\fO[F]  as  shown  in  Figure  3.4.  That  is,  we  can  think  of 
a  function  family  F  :  IC  x  M  ^  {0, 1}”,  such  as  a  block  cipher,  as  a  nonce-based 
encryption  function  AfO[F]  :  /C  x  A/”  x  Af  — (0, 1}”  where  AfO[F]K  throws  away  the 
second  argument  and  just  enciphers  the  nonce  (and  J\f  =  Ad).  Obviously,  we  can’t  extract 
M  from  the  result,  so  the  decryption  function  is  empty. 


71 


Algorithm  A/'C»[F]  .Encrypt^  (iV,  M):  Algorithm  A/'C>[F]. Decrypt^  (C): 

return  Fk{N)  return  ^ 

Figure  3.4:  “Nonce-only”  function  MO[F]. 

Lemma  2  (IND$-CPA /or  addr)  Let  F  be  a  family  of  functions  IC  x  Ai  ^  {0, 

Assume  that  all  IND$-CPA  adversaries  are  nonce-respecting.  Then 

<  AdvP''^(/,g,cT) 

where  t'  =  t  +  0{a). 

Proof  Sketch  Suppose  we  have  an  IND$-CPA  adversary  A  attacking  J\fO[F].  We 
construct  a  prf  adversary  B  attacking  F  as  follows: 

1.  When  A  makes  a  query  (A^,  M)  to  its  oracle,  pass  N  to  B"s  oracle. 

2.  When  A  outputs  b,  B  outputs  b. 

Note  that,  from  the  perspective  of  A,  B  simply  implements  J\fO[F],  where  F  is  A’s 
oracle. 

Adv'^f^B)  =  FT[k  ^  /C  :  ff  Rand(Af,  {0, 1}'^)  :  =  1] 

=  Pr[A;  ^  /C  :  =  x]  _  ^  Rand(/d,  {0, 1}'^)  :  A^')  =  1] 

=  Pr[A;  ^  /C  :  =  x]  _  p^fp  ^  Rand(/A,  {0,  l}*^)  :  ’  =  x] 

=  AdvXf^^^(A) 

The  third  equality  can  be  shown  as  follows:  A  is  nonce-respecting  so  each  query  it  submits 
to  p(-)  will  be  different.  Moreover,  the  range  of  F  is  {0, 1}”  so  outputs  of  ffO[F]k{-,  ■) 
are  all  of  length  n.  Therefore,  the  behavior  of  p(-)  is  indistinguishable  from  - 


Security  of  enckey.  The  following  Lemma  shows  enckey  is  IND$-CPA-secure. 


Lemma  3  (IND$-CPA/or  enckey)  Assume  that  all  IND$-CPA^  adversaries  are  random- 
nonce  adversaries  and  all  IND$-CPA  adversaries  are  nonce-respecting.  Then 


Adv 


IND$-CPA' 

MO[F\ 


{t,q,a) 


<  Adv 


IND$-CPA 

AfO[F] 


(t',  q,  a)  + 


q{q  - 1) 

2n+l 


where  t'  =  t  +  0(a). 
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Proof  Sketch  If  IND$-CPA^  adversary  A  never  submits  the  same  query  twice,  then  it 
is  nonce-respecting  and  has  at  most  the  same  advantage  as  the  best  nonce-respecting  ad¬ 
versary.  The  likelihood  that  it  submits  the  same  query  twice  is  at  most  (the  birthday 
bound).  ■ 

Security  of  mac  and  emac.  The  following  Lemma  from  Iwata  et  al.  [83]  shows  that 
CMAC  is  prf-secure.  By  Lemma  2,  it  is  also  IND$- CPA-secure  if  the  input  is  different 
each  time. 

Lemma  4  (pri  for  CMAC)  [83]  Let  E  :  }C  x  {0, 1}”  — (0, 1}”  be  the  underlying  block 
cipher  in  CMAC  (a.k.a.  XCBC).  Then 

Adv^MAc(^>  g,  <  ^  +  Advg'P(f',  a) 

where  t'  =  t  +  0{a). 


Security  of  etext.  The  following  Lemma  from  Rogaway  [139]  shows  that  CTR2  mode 
encryption  is  IND$-CPA-secure. 

Lemma  5  (IND$-CPA/or  etext)  [139]  Let  E  :  iCx  {0, 1}^  {0, 1}'^  be  the  underlying 

block  cipher  in  CTR2.  Let  n,a  >1.  Then 

+  Advg'P(t',a) 

where  f  =  t  +  0{a). 

Note  that  although  we  always  use  0^^®  as  the  IV  in  Tryst’s  encryption  of  the  payload 
p,  we  use  a  different  encryption  key  each  time.  Therefore,  the  protocol  is  still  nonce- 
respecting  in  that  the  IV  is  only  used  once  per  encryption  key. 

Combining  components.  Finally,  the  following  two  Lemmas  demonstrate  how  to  de¬ 
scribe  the  security  when  combining  IND$-CPA-secure  and  ENCAP-IND$-CPA-secure 
constituent  parts. 


Lemma  6  (IND$-CPA  ^  ENCAP-IND$-CPA)  Let  n(n)  =  (/C,  S,  T>)  be  an  encryption 
scheme.  Assume  that  all  ENCAP-IND$-CPA  and  IND$-CPA  adversaries  are  nonce- 
respecting.  Then 


where  t' 


Adv^NCAP-INDS-CPA 


(t,  g,  a)  <  Adv 


IND$-CPA 

n(n) 


(t',  g,  a) 


t  -f  0{a). 
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Algorithm  J^C[fi, fm]{Dn,  •  •  • ,  ^ifc,  •  •  • ,  ^mi,  •  •  • , 

return  fi{Du, Dik)\\  ■■■  \\fm{Dmi,  ■■■,  Dmk) 

Figure  3.5:  Encapsulation  function  “combiner”  jFC[Fi, . . . ,  Fm] 


Proof  Sketch  Suppose  we  have  an  ENCAP-IND$-CPA  adversary  A  attacking  S.  Con¬ 
struct  an  IND$-CPA  adversary  B  attacking  11  (n)  as  follows: 

1.  When  A  asks  a  query  to  its  oracle,  pass  it  to  B’s  oracle. 

2.  When  A  outputs  bit  b,  output  b. 


B's  oracle  is  the  same  as  A’s  oracle  (an  encryption  function  chosen  randomly  from  S, 
or  a  random  sequence  of  bits  of  the  same  length).  Therefore  B  will  answer  correctly  if  and 
only  if  A  answers  correctly.  ■ 

Let  Fi(n,  /i,  /ci), . . . ,  Fm{n,  Im,  km)  be  encapsulation  function  families  such  that  Fi  : 
Vii  X  ...  X  Vik  TZi.  Define  a  encapsulation  function  family  FC[Fi, . . .  ,Fm\  as  in 
Figure  3.5,  where  each  distinct  member  of  FC[Fi, . . . ,  Fm]  is  defined  by  choosing  one 
function  in  each  family  Fi.  That  is,  a  function  FC[fi, . . . ,  fm]  simply  comprises  one  func¬ 
tion  /i  G  Fi,  f 2  G  F2,  etc.,  takes  as  input  all  the  inputs  of  each  ft,  and  returns  the 
concatenation  of  the  result  of  each.  The  members  of  BC[fi, . . . ,  fm]  are  distinguished  by 
the  combined  keys  of  all  its  components.  Therefore,  it  has  U  inputs  and  its  security 
parameter  is  n  ■  h. 


Lemma  7  (ENCAP-IND$-CPA  Combiner)  Let  Fi{n,  li,  ki), .  ■  ■ ,  Fm{n,  Im,  km)  be  en¬ 
capsulation  function  families  such  that  Fi  :  Fn  x  . . .  x  Fu^  — >  TZi.  Then 


A  I  ENCAP-IND$-CPA 


{t,q,a)  <  ^Adv 


ENCAP-IND$-CPA 

F, 


{t',  q,  a) 


where  t'  =  t  +  0(a). 


Proof  Sketch  We  prove  this  claim  using  induction  on  m. 

Base  case.  FC[fi]  =  fi.  Therefore,  g,  a)  =  g,  a). 

Inductive  case.  Assume  the  inductive  hypothesis: 

ENCAP-IND$-CPA/ 


Adv 


PjlNUAr-ilNJJai-tJT^A/ .  \  ^ 


m 
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We  want  to  show  the  following: 


m+1 


Adv 


ENCAP-IND$-CPA 


(A  g,  Adv 


ENCAP-IND$-CPA 

Fi 


{t',q,a) 


Suppose  we  have  an  ENCAP-IND$-CPA  adversary  B  attacking  BC[Fi, . . . ,  Fm+i\. 
To  prove  the  above  claim,  we  construct  two  ENCAP-IND$-CPA  adversaries  from  B:  Ai 
attacks  F^+i  and  A2  attacks  the  inductive  hypothesis. 

Adversary  Ai: 

R 

1.  For  i  e  {1, . . . ,  m}  construct  fi  ^  F^. 

2.  When  B  makes  an  oracle  query  . . . ,  •  •  • ,  A>m+i,u+i)’  pass 

{Dra+1,1-,  ■  ■  ■  ■,F)m+i,irr,+i)  to  Ai’s  oraclc  to  obtain  the  result  o. 

Return  . . . ,  A>i,zJ||  . . .  •  •  • ,  D^^iJ\\o. 

3.  When  B  outputs  bit  b,  output  b. 


Note  that  in  the  case  where  Ai ’s  oracle  is  fm+i ,  this  adversary  implements  FC  [Fi , . . . ,  F^+i] 
as  the  oracle  for  B.  Therefore,  Ai  has  the  following  advantage: 


AdvENCAP-IND$-CPA 
''  Fm  +  l 


(Ai)  =  Pr 
Pr 


f  Fl  T?  f  A  T? 

Jl  ^  Fl)  •  •  •  )  /rn-H  F , 


I  m+l 

fm+l 


m+l 

1 

m+l 


■  ]^FC[fl,...Jm+l]  _ 


/i  ^  Fi, . . . ,  /„,+!  ^  =  1 


where  FCr[/i,  . .  .J^+i]  is  a  function  that  takes  ■  ■  .,Dm+i,i^+,) 

returns  $l/i(^i.p-Fi.n)l||  . . .  . .  .,Dm+iu+^)- 


Adversary  A2 


R 

1.  Construct /^+i  ^  F^+i. 

2.  When  B  makes  an  oracle  query  (£>1,1, . . . ,  ,  Dm+i,i,  •  •  • ,  Fm+i,z„+i),  pass 

(F14, . . . ,  ,  Fm,i, . . . ,  to  A2’s  oracle  to  obtain  the  result  o. 

Return 

3.  When  B  outputs  bit  b,  output  b. 
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Note  that  in  the  case  where  A2"s  oracle  is  this  adversary  implements 

Therefore,  A2  has  the  following  advantage: 


A  J,,ENCAP-IND$-CPA 


(A2)  =  Pr 
Pr 

where  TCji[fi, . . . ,  fm+i]  is  defined  above. 
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We  then  have: 
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The  first  equality  is  by  the  definition  of  ENCAP-IND$-CPA.  The  second  equality  is  due 
to  the  addition  and  subtraction  of  the  same  quantity.  The  third  equality  is  by  substitution 
with  the  adversaries’  advantages  shown  above.  The  final  inequality  is  by  the  inductive 
hypothesis.  ■ 


3.5.3  Security  of  Tryst  and  Shroud 

Finally,  in  this  section,  we  show  how  to  describe  the  security  of  the  Tryst  and  Shroud 
encapsulation  functions,  which  are  combinations  of  functions  described  in  the  previous 
section. 

Theorem  3.5.1  fENCAP-IND$-CPA/or  tryst  j  Let  tryst  \  IC  x  J\f  x  A4  be  the  encapsu¬ 
lation  function  described  in  Section  3.3.3,  where  J\f  is  the  value  enciphered  to  create  the 
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address  addr  and  M.  is  the  plaintext  payload.  If  SH A 1  ±28  {■)  is  a  random  oracle,  then 

Aj„encap-ind.-cpA(j_  +  5  .  Ad„™  («'.  <t) 

where  t'  =  t  +  0{a)  for  any  adversary  that  makes  at  most  one  query  per  time  interval  ( i.  e., 
chooses  different  N  G  M  for  each  query). 

Proof  Sketch  We  analyze  an  adversary’s  advantage  by  determining  its  maximal  ad¬ 
vantage  of  attacking  each  individual  part  of  the  output:  addr  =  addr^^,  enckey  = 
AES  f.Enc  (kp),  mac  =  AES-CMAC;i,MAc  (s),  etext  =  AES-CTR2fcpj  (0^^®,p),  and  emac  = 
AES-CMACfcp2  (etext).  Note  that  the  secret  key  input  the  encryption  scheme  in  each  of 
these  parts  is  different  (kpi  and  kp2  are  random  if  SHA1 128  (■)  is  a  random  oracle).  There¬ 
fore,  each  component  is  selected  randomly  from  their  respective  encryption  function  fam¬ 
ilies.  Thus,  we  can  use  Lemma  7  to  obtain  a  bound  on  the  advantage  the  adversary  has  on 
the  tryst  function  as  a  whole. 

If  an  adversary  makes  at  most  one  query  per  time  interval,  then  the  addr  part  of  the 
output  is  an  instance  of  A/’C1[AES]  because  the  nonce  input  will  be  different  each  time.  By 
Lemma  2  and  Lemma  6,  an  IND$-CPA  adversary’s  advantage  attacking  the  addr  part  is 
at  most  Adv^’'4(^>  7)  <  Adv^1g(f,  q)  +  (by  Lemma  1). 

The  enckey  part  is  an  instance  of  A/’(9[AES]  where  each  input  is  random.  By  Lemma  3, 
the  ENCAP-IND$-CPA  adversary’s  advantage  attacking  the  enckey  part  is  at  most 
Adv™0®2VE^^(^>  7)  +  '^gn+i^  •  By  applying  Lemma  2,  Lemma  6,  and  Lemma  1  as  before, 

we  obtain  that  the  advantage  is  at  most  Adv^gg(f,  q)  + 

The  mac  part  is  an  instance  of  CMAC.  By  Lemma  4,  the  prf  adversary’s  advantage  at¬ 
tacking  the  mac  part  is  at  most  -|- Adv^'^g  (f,  am)  where  am  is  the  sum  of  the  sizes  of  the 
inputs  to  CMAC  and  t  =  t+0(am)-  The  output  size  is  the  same  for  all  inputs  and  all  inputs 
are  different,  so  the  prf  property  becomes  indistinguishable  from  the  ENCAP-IND$-CPA 
property  and  this  is  also  a  bound  on  the  ENCAP-IND$-CPA  advantage  of  attacking  the 
mac  part. 

The  etext  part  is  an  instance  of  CTR2.  By  Lemma  5,  the  IND$-CPA  adversary’s 

2 

advantage  is  at  most  ^  -f  Adv^'|g(t',  ap)  where  ap  is  sum  of  the  sizes  of  plaintexts  p  and 
i  =  t  +  0(ap).  By  Lemma  6,  this  is  also  the  bound  on  the  ENCAP-IND$-CPA  advantage 
of  attacking  the  etext  part. 

The  emac  part  is  an  instance  of  CMAC.  By  Lemma  4,  the  prf  adversary’s  advantage 
attacking  the  mac  part  is  at  most  -f  Adv^’^g(t,  ap)  where  ap  is  sum  of  the  sizes  of 
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plaintexts  |p|  and  i  =  t  +  0(ap).  The  output  size  is  the  same  for  all  inputs,  so  the  prf 
property  becomes  indistinguishable  from  the  ENCAP-IND$-CPA  property  and  this  is 
also  a  bound  on  the  ENCAP-IND$-CPA  advantage  of  attacking  the  mac  part. 


The  tryst  encapsulation  function  is  just  a  concatenation  of  the  aforementioned  parts,  so 
by  Lemma  7,  an  ENCAP-IND$-CPA  adversary’s  advantage  attacking  tryst  is  at  most  the 
sum  of  the  aforementioned  advantages: 


2  ■  Adv^''|g(t,  q)  +  Adv^"Pg(f,  a^)  +  2  ■  Adv^"Pg(t,  ap)  + 


1.5  ■  q{q  -  1)  3a, 


+ 


+ 


4a2 


a 


<  5-AdvP''|g(t',a)  +  9-  — 


where  a  is  the  sum  of  the  sizes  of  all  input  to  the  tryst  function  (i.e.,  the  length  of  each 
packet)  and  t'  =  t  +  0{a).  m 


Tryst  takes  4  =  0(1)  keys,  and  the  bound  given  by  Theorem  3.5.1  is  clearly  negligible 
in  An  assuming  that  Adv^^|g(f',  q,  a)  is  also  negligible  in  n  (i.e.,  AES  is  a  good  random 
permutation).  Thus,  Tryst  is  ENCAP-IND$-CPA-secure  if  we  limit  the  adversary  to  one 
query  per  time  interval.  However,  note  that  we  only  require  this  limitation  in  order  to  make 
the  adversary  nonce-respecting  for  the  addr  part  of  the  Tryst  function.  Therefore,  if  we 
consider  all  parts  of  the  Tryst  function  except  the  addr  part.  Tryst  is  ENCAP-IND$-CPA- 
secure  even  without  this  restriction.  This  result  is  intuitively  obvious  since  the  addr  is  fixed 
for  each  time  interval  so  multiple  queries  would  result  in  the  same  addr,  which  is  clearly 
not  random. 


Theorem  3.5.2  (ENCAP-IND$-CPA/or  shroud)  Let  shroud  :  1C  x  J\f  x  M.  be  the  en¬ 
capsulation  function  described  in  Section  3.3.4,  where  M  is  the  value  enciphered  to  create 
the  address  addr  and  M.  is  the  plaintext  payload.  Then 

+  3  ■  Adv"  (*'.  a) 

where  t'  =  t  +  0{a)  for  any  nonce-respecting  adversary  (i.e.,  chooses  different  N  E  J\f 
for  each  query). 

The  proof  is  similar  to  the  proof  for  Theorem  3.5.1,  so  we  omit  the  details  here.  The 
only  significant  difference  is  that  we  do  not  limit  the  adversary  to  one  query  per  time 
interval  because  the  nonce  input  to  addr  is  different  for  each  packet  in  Shroud. 

Shroud  takes  3  =  0(1)  keys,  and  the  bound  given  by  Theorem  3.5.2  is  clearly  negligi¬ 
ble  in  4n  assuming  that  Adv^gg(t',  a)  is  also  negligible  in  n.  Thus,  Shroud  is  ENCAP-IND$-CPA- 
secure. 
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3.6  Robustness  Against  Attacks 


SlyFi  is  designed  to  achieve  unlinkability,  confidentiality,  authenticity,  and  message  in¬ 
tegrity  under  the  threat  model  described  in  Section  3.2.1:  we  assume  scenarios  where 
adversaries  are  passive  eavesdroppers,  they  are  not  privy  to  any  of  the  secret  keys  shared 
between  senders  and  receivers,  they  cannot  gain  much  useful  information  from  timing  and 
physical  layer  side-channels,  and  there  are  a  sufficient  number  of  honest  senders  trans¬ 
mitting  simultaneously.  The  empirical  results  we  presented  in  Section  3.2.1  (in  addition 
to  subsequent  work  [18,  19])  demonstrate  that  these  assumptions  are  reasonable  in  many 
circumstances.  In  this  section,  we  discuss  the  resilience  of  SlyFi  to  more  powerful  adver¬ 
saries  when  these  assumptions  are  relaxed. 


3.6.1  Replay  and  Active  Attacks 

An  adversary  can  replay  a  Tryst  message  for  up  to  A;  ■  J  time  units  after  it  was  initially  sent 
and  the  receiver  will  still  process  it.  This  is  because  the  receiver  must  account  for  k  ■  I 
units  of  clock  skew.  If  the  receiver  is  present  during  the  replay,  then  it  will  respond  with 
a  Tryst  probe  response.  Without  additional  information,  the  adversary  can  not  determine 
that  this  message  is  a  response  to  his  probe,  but  even  if  he  can,  it  does  not  explicitly  reveal 
any  information  about  the  receiver. 

However,  if  an  adversary  knows  the  sender  or  intended  recipient  of  a  Tryst  probe, 
the  presence  or  absence  of  a  reply  may  reveal  additional  information.  For  example,  an 
adversary  can  replay  a  probe  at  another  location  to  see  if  the  recipient  responds.  However, 
these  attacks  can  only  be  performed  for  the  short  time  interval  that  an  address  is  valid 
and  can  be  mitigated  by  simple  countermeasures.  For  example,  since  an  adversary  cannot 
distinguish  the  content  of  a  response  from  any  other  message,  if  random  delays  were  added 
to  probe  responses,  an  adversary  might  lose  them  in  the  noise  of  frequent  background 
traffic.  In  addition,  receivers  can  cache  valid  probe  and  authentication  requests  that  they 
receive  for  the  duration  they  are  valid  and  ignore  replays  of  those  messages.  We  did  not 
implement  these  countermeasures  since  these  attacks  assume  adversaries  already  know  the 
sender  or  intended  recipient  of  a  message,  which  can  not  be  learned  from  the  message’s 
contents  alone. 

Shroud  messages  that  are  replayed  will  not  be  processed  by  the  receiver  because  each 
address  is  only  valid  for  a  single  message. 
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3.6.2  Denial-of-Service  Attacks 


Wireless  is  a  broadcast  medium  and  the  unlicensed  nature  of  the  802. 1 1  spectrum  makes 
it  easy  for  an  adversary  to  jam  a  channel  by  broadcasting  “junk.”  Junk  messages  will 
interfere  with  valid  messages  sent  and  devices  that  receive  junk  messages  may  be  forced 
to  process  them.  An  important  metric  for  measuring  how  susceptible  a  wireless  protocol 
is  to  such  denial-of-service  attacks  is  the  amount  of  energy  an  adversary  has  to  spend 
to  prevent  a  receiver  from  receiving  useful  messages  [69].  In  this  respect,  SlyFi  is  no 
more  susceptible  to  denial-of-service  attacks  than  802.11  because,  as  we  demonstrate  in 
Section  3.7,  it  can  process  all  messages  that  it  receives,  adversarial  or  otherwise,  at  the 
maximum  wireless  bit  rate.  We  note  that  this  is  in  contrast  to  the  straw  men  protocol  we 
described  in  Section  3.3.1.  Junk  messages  can  interfere  with  valid  SlyFi  messages,  but  the 
same  is  true  for  802. 1 1  messages. 

3.6.3  Logical  Layer  Side-Channel  Attacks 

To  achieve  strong  unlinkability,  SlyFi  assumes  that  an  adversary  can  not  distinguish  the 
packets  belonging  to  different  packet  streams  sent  simultaneously.  In  practice,  some  side- 
channels,  such  as  packet  sizes  and  the  time  when  packets  are  sent  may  hint  at  the  packet 
stream  each  packet  belongs  to.  Nonetheless,  since  the  majority  of  side-channel  attacks 
on  short  term  packet  linkability  require  a  relatively  large  number  of  linked  packets  to  be 
effective  (e.g.,  [142,  171,  172]),  we  believe  that  Shroud  will  still  make  such  attacks  much 
more  difficult  to  carry  out  in  environments  with  many  overlapping  packet  streams. 

In  scenarios  where  there  is  only  one  transmitter,  there  will  obviously  be  no  ambient 
traffic  to  mask  that  transmitter’s  packet  stream.  In  Section  3.2.1,  we  described  evidence 
that  may  packet  streams  do  overlap  in  practice,  so  we  believe  that  these  scenarios  are  rare. 
In  scenarios  where  packet  sizes  and  timing  may  be  sufficiently  distinguishing  to  perform 
side  channel  attacks,  existing  countermeasures  such  as  packet  padding  and  cover  traffic  can 
complement  SlyFi  and  prevent  these  attacks  (albeit  at  significantly  higher  cost).  Deciding 
when  to  employ  these  additional  countermeasures  is  an  important  area  of  future  work. 

3.6.4  Physical  Layer  Side- Channel  Attacks 

Radio  fingerprints  at  the  physical  layer  may  be  detected  by  adversaries  with  special  equip¬ 
ment  [16,  36,  70,  143].  SlyFi  does  not  conceal  these  fingerprints  in  Tryst  or  Shroud  pack¬ 
ets.  However,  we  believe  that  such  equipment,  such  as  high  precision  signal  analyzers 
that  cost  tens  of  thousands  of  dollars,  are  out  of  reach  of  casual  eavesdroppers  and  do  not 
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expect  large  scale  surveillance  networks  constructed  using  them  soon.  We  also  believe 
that  concealing  these  fingerprints  with  hardware  modifications  is  not  technically  difficult 
(e.g.,  Brik  et  al.  [36]  used  fixed  calibration  errors  to  fingerprint  wireless  cards,  so  insert¬ 
ing  randomized  noise  to  these  errors  would  mask  the  fingerprints).  However,  doing  so 
would  likely  add  to  the  cost  of  wireless  devices,  so  a  thorough  understanding  of  the  eco¬ 
nomic  trade-offs  is  a  crucial  topic  of  future  work  to  determining  whether  deploying  such 
countermeasures  at  scale  is  practical. 

More  accessible  physical  layer  information  such  as  signal  strength  may  also  some¬ 
times  act  as  side  channels  that  link  messages  together  at  short  time  scales.  However,  these 
implicit  identifiers  are  typically  less  distinguishing  than  logical  layer  fingerprints.  For 
example,  Tao  et  al.  [153]  and  Bahl  and  Padmanabhan  [12]  show  that  signal  strength  mea¬ 
surements  from  multiple  locations  can  be  used  to  distinguish  the  rough  locations  where 
they  originated.  Therefore,  when  devices  are  stationary,  they  can  approximately  distin¬ 
guish  the  messages  sent  by  each  one.  Nonetheless,  Bauer  et  al.  [18,  19]  find  that,  while 
using  multiple  signal  strength  measurements  to  distinguish  messages  sources  can  be  mod¬ 
erately  accurate,  the  error  rate  is  sufficiently  high  that  certain  side-channel  attacks  (e.g., 
[105])  have  much  lower  success  rates  (e.g.,  50%  vs.  95%).  Moreover,  collecting  sufficient 
signal  strength  measurements  requires  multiple  monitoring  points  and  their  accuracy  can 
be  reduced  by  varying  a  client’s  transmit  power  [18,  19]. 


3.6.5  Tryst  Key  Compromise 

Tryst  secret  keys  are  bootstrapped  through  an  out-of-band  mechanism  that  we  assume  is 
secure.  As  with  802.11  WPA  today,  a  secret  password  may  be  used  to  derive  these  keys. 
The  strength  of  Tryst’s  security  would  then  depends  on  the  strength  of  the  password,  which 
may  be  weak  if  it  is  defined  by  a  human.  One  way  to  limit  the  window  of  vulnerability  to 
weak  passwords  is  to  use  keys  derived  from  the  password  only  for  the  first  Tryst  probe  and 
response.  These  messages  can  contain  new  truly  random  keys  used  for  future  discovery 
attempts  (using  different  keys  for  each  receiver).  This  will  ensure  that  an  adversary  that 
compromises  the  initial  key  can  only  compromise  the  confidentiality  and  unlinkability  of 
messages  if  they  overhear  the  first  Tryst  probe  and  response.  More  generally,  a  sender  and 
receiver  can  renegotiate  keys  each  time  they  engage  in  a  session. 

If  a  secret  key  is  compromised  in  some  other  manner  (e.g.,  if  an  adversary  extracts  it 
from  one  of  the  devices  manually).  Tryst  can  not  protect  the  confidentiality  or  unlinkability 
of  future  messages.  However,  the  confidentiality  and  unlinkability  of  messages  transmit¬ 
ted  on  previous  days  remains  protected  because  Tryst  uses  a  forward-secure  random  bit 
generator  to  change  keys  each  day  (see  Section  3.4.1). 
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3.6.6  Shroud  Key  Compromise 


Shroud  session  keys  are  less  likely  to  be  eompromised  beeause  they  will  only  be  used 
for  short  time  periods  and  need  not  be  resident  on  long  term  storage.  Moreover,  they  are 
randomly  generated.  To  reduee  the  likelihood  of  eompromise  even  further,  senders  and  re- 
eeivers  ean  periodieally  renegotiate  new  Shroud  keys  during  a  session  in  a  manner  similar 
to  WPA.  If  a  set  of  Shroud  keys  are  eompromised,  the  eonfidentiality  and  unlinkability  of 
the  session  that  those  keys  are  proteeting  are  lost. 


3.6.7  Adversarial  Senders  and  Receivers 

SlyFi  does  not  proteet  users  if  they  do  not  trust  the  deviee  that  they  are  eommunieating 
with  (e.g.,  if  a  user  does  not  trust  the  AP  he  is  using  or  vis  versa).  In  sueh  seenarios,  users 
eould  instead  assoeiate  with  untrusted  deviees  anonymously,  as  users  do  at  open  802. 1 1 
APs  today  if  they  ehange  their  MAC  address.  To  proteet  the  information  they  transmit 
through  untrusted  deviees,  users  would  have  to  rely  on  existing  heavy-weight  measures, 
sueh  as  enerypting  and  tunneling  all  traffie  through  a  trusted  VPN  or  mix  network.  SlyFi 
is  an  optimization  to  these  solutions  when  both  ends  of  the  wireless  link  trust  eaeh  other. 


3.7  Performance  Evaluation 

We  evaluate  two  key  areas.  First,  we  examine  how  quiekly  we  ean  diseover  and  set  up  a 
link  with  Tryst.  A  quiek  link  establishment  improves  usability  both  by  redueing  the  delay 
before  eommunieation  ean  begin  and  by  preventing  notieeable  interruptions  when  roaming 
between  APs.  Seeond,  we  examine  the  performanee  penalty  ineurred  when  using  Shroud 
to  deliver  data  traffie.  In  general,  we  find  that  SlyFi  performs  eomparably  to  802.1 1  using 
WPA  and  substantially  out-performs  the  straw  man  meehanisms  we  diseussed. 


3.7.1  Comparison  Protocols 

We  eompare  our  SlyFi  implementation  to  the  following  baseline  protoeols  and  alternatives: 

wifi-open.  The  baseline  implementation  of  802. 1 1  without  WEP  or  WPA  in  Cliek.  SlyFi 
uses  the  same  eomponents,  simply  eneapsulating  the  original  paekets  where  needed,  allow¬ 
ing  us  to  make  a  direet  eomparison  to  a  software  implementation  without  our  meehanisms. 
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wifi-open-driver.  The  802.11  implementation  in  the  MadWifi  driver/firmware  [110]. 
We  compare  to  this  second  baseline  since  wifi-open  has  additional  overhead  when  used 
for  data  transport,  which  we  discuss  in  Section  3.7.4.  Neither  wifi-open  nor  wifi-open- 
driver  meet  any  of  our  security  requirements. 

wifi-wpa.  A  baseline  implementation  of  802.11  with  WPA,  which  provides  authentica¬ 
tion,  message  integrity,  and  confidentiality,  but  not  unlinkability  as  messages  still  include 
Ethernet  addresses  and  network  names.  We  use  the  standard  WPA  client  and  AP  imple¬ 
mentations  on  Linux  [77],  which  run  on  top  of  wifi-open-driver,  so  wifi-wpa  does  not 
incur  the  overhead  mentioned  above.  We  run  wifi-wpa  using  PSK  user  authentication 
and  CCMP  encryption.  PSK  is  the  most  widely  used  standard  in  small  private  networks. 
CCMP  is  comparable  to  SlyFi’s  payload  encryption,  as  both  are  built  around  AES.  How¬ 
ever,  wifi-wpa  performs  AES  operations  using  dedicated  hardware  on  the  802.11  NIC, 
while  SlyFi  performs  it  in  software.  To  compensate,  we  also  evaluate  SlyFi  with  simu¬ 
lated  hardware  we  discuss  in  Section  3.7.4. 

public  key.  The  straw  man  alternative  to  Tryst  for  discovery  and  link  setup  discussed  in 
Section  3.3.1. 

symmetric  key.  The  other  straw  man  alternative  to  Tryst  discussed  in  Section  3.3.2. 
public  key  and  symmetric  key  still  use  Shroud  once  a  link  is  established  (i.e.,  they  only 
replace  Tryst  in  Figure  3.1). 

armknecht.  A  previous  802.11  frame  encryption  proposal  [11]  that  is  an  alternative 
to  Shroud  for  data  transport.^  Like  Shroud,  armknecht  computes  per-packet  addresses, 
but  only  for  the  next  packet  it  expects,  so  it  would  perform  comparably  when  there  is 
no  packet  loss  or  competing  traffic.  However,  a  receiver  that  receives  a  message  without 
one  of  its  known  addresses  performs  a  number  of  cryptographic  operations  comparable  to 
symmetric  key  before  discarding  it.  This  is  because  it  treats  a  packet  it  does  not  have  an 
address  for  as  an  indication  of  potential  loss  and  uses  these  operations  to  try  to  recover 
from  it.  In  contrast.  Shroud  simply  precomputes  more  addresses  to  manage  loss. 


3.7.2  Setup 

We  deploy  these  protocols  on  a  number  of  Soekris  net4801  low-power  devices  [146]. 
These  devices  have  hardware  comparable  to  common  802.11  APs  and  embedded  con¬ 
sumer  devices.  While  laptops  have  more  powerful  hardware,  we  demonstrate  that  our 

^Our  implementation  uses  AES  as  the  cipher. 
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mechanisms  are  usable  even  on  more  constrained  devices.  In  our  experiments,  we  desig¬ 
nate  each  device  as  either  an  AP  or  a  client. 

Each  device  has  a  266  Mhz  586-class  Geode  processor,  256  MB  of  RAM,  1  GB  of 
flash  storage,  and  one  CM9  Atheros  802.11a/b/g  miniPCI  card.  Each  device  runs  a  min¬ 
imal  version  of  Linux  2.6.16.13.  802.11  frames  are  sent  and  received  from  a  raw  802.11 
radiotap  device  created  by  the  standard  MadWifi  driver.  We  operate  on  802.1  la  channel  40 
to  avoid  interference  from  more  common  802.11b/g  devices.  To  make  a  fair  comparison, 
management  frames  in  all  protocols  are  transmitted  at  the  base  rate  (6Mbps),  as  is  dictated 
by  the  802.1 1  standard,  while  data  frames  are  transmitted  at  the  peak  rate  (54Mbps). 


3.7.3  Discovery  and  Link  Setup  Performance 

To  evaluate  how  long  a  client  would  need  wait  before  it  can  start  transferring  data,  we 
measure  the  link  setup  time,  defined  as  the  delay  between  when  a  client  begins  probing  for 
APs  and  when  it  can  deliver  packets  on  the  established  link.  In  all  the  protocols  except  for 
wifi-wpa,  packets  can  be  delivered  once  an  association  response  message  is  received  (see 
Eigure  3.1).  wifi-wpa  has  an  additional  key  negotiation  phase  after  association. 

The  parameters  that  impact  link  setup  time  are:  the  number  of  client  accounts  on  an 
AP,  the  number  of  networks  that  each  client  probes  for,  and  the  amount  of  background 
probing  traffic  that  is  overheard  by  APs  and  clients.  Our  results  show  that,  in  contrast  to 
public  key  and  symmetric  key.  Tryst  has  faster  link  setup  times  than  wifi-wpa  and  scales 
as  gracefully  as  wifi-open  when  varying  each  of  these  parameters.  Moreover,  the  cost  of 
periodically  computing  addresses  is  trivial.  Unless  otherwise  indicated,  each  data  point 
presented  in  this  section  is  the  mean  of  30  trials. 

Keys  per  service.  An  AP  maintains  one  key  for  each  client  it  has  an  account  for,  and  the 
total  number  of  keys  can  impact  link  setup  time.  Real  networks  manage  various  numbers  of 
client  accounts;  e.g.,  home  networks  will  likely  have  less  than  a  dozen,  while  the  wireless 
network  at  the  Intel  Research  lablets,  a  fairly  small  organization,  has  721.  Carnegie  Mellon 
University’s  wireless  network,  which  may  be  representative  of  a  large  organization,  has 
36,837  at  the  time  of  this  writing. 

Eigure  3.6  shows  the  link  setup  time  for  a  client  that  sends  one  probe  in  search  of  a 
nearby  AP  as  we  vary  the  number  of  keys  per  AP.  Before  each  probe,  the  AP  has  its  keys 
sorted  in  random  order,  and  thus,  the  performance  of  the  symmetric  key  protocol  degrades 
with  the  number  of  keys,  since  it  must  check  a  discovery  message  against  all  keys  until 
it  finds  one  that  successfully  validates  the  MAC  on  the  header.  The  other  protocols  have 
setup  times  that  are  independent  of  the  number  of  keys  per  AP.  Note  however,  that  the 
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Figure  3.6:  Association  delay  as  the  number  of  keys  per  AP  varies.  The  client  probes  for 
1  AP.  Error  bars  indicate  one  standard  deviation. 


public  key  protocol  is  still  more  expensive  than  all  the  others,  even  when  the  AP  has 
10,000  keys.  Furthermore,  although  Tryst  imposes  some  overhead  over  the  wifi-open 
protocol,  it  has  link  setup  times  that  are  less  than  wifi-wpa  and  that,  at  ~15  ms,  are  below 
the  variance  in  Internet  round  trip  times. 

Probes  per  client.  Since  private  APs  cannot  send  beacons,  a  client  may  need  to  probe 
for  several  different  networks  to  figure  out  which  one  is  present.  In  802.11,  these  probes 
usually  contain  the  names  of  networks  with  which  the  client  has  previously  associated. 
Figure  3.7  shows  a  cumulative  distribution  function  of  the  number  of  unique  network 
names  probed  for  by  clients  in  three  wireless  traces  (described  in  Table  3.1).  While  most 
users  probe  for  a  small  number  of  networks,  at  least  4%  of  users  in  all  traces  probe  for 
more  than  10  and  some  probe  for  more  than  100.^  Therefore,  it  is  important  that  link  setup 
time  does  not  grow  substantially  with  the  number  of  probes. 

Figure  3.8  shows  the  link  setup  time  as  a  function  of  the  number  of  different  probes 
a  client  sends,  which  are  sent  as  fast  as  possible.  The  number  of  keys  per  AP  is  fixed  at 

®Users  in  the  SIGCOMM  trace  probed  for  more  networks  because  each  SIGCOMM  AP  had  a  different 
network  name  and  the  network  often  was  unavailable,  prompting  clients  to  send  probes  for  names  deeper 
into  their  list  of  networks.  We  ignored  broadcast  and  random  network  names. 
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Figure  3.7:  CDF  of  the  number  of  unique  network  names  probed  for  by  each  client  in  three 
empirical  802.11  traces. 


500.  For  a  fair  comparison,  Tryst  sends  a  separate  message  for  each  probe  instead  of  using 
scoped  broadcast  (discussed  in  Section  3.3.3).  We  omit  the  line  for  wifi-wpa  because  the 
standard  probing  behavior  is  different  and  incurs  more  delays.  If  it  also  sent  probes  as  fast 
as  possible,  it  would  have  scaling  behavior  similar  to  the  wifi-open  line  since  the  probes 
they  send  are  the  same. 

Although  all  protocols  scale  with  the  number  of  probes  sent,  as  there  is  overhead  in 
processing  them  and  limited  bandwidth  in  the  medium,  the  slopes  of  the  two  straw  man 
protocols  are  steeper,  indicating  that  they  incur  more  overhead  per  probe.  The  slopes  of 
the  Tryst  and  wifi-open  lines  are  similar,  and  both  have  setup  times  of  at  most  ~50  ms 
even  when  clients  send  50  probes. 

Performance  breakdown.  Table  3.3  shows  the  breakdown  of  link  setup  time  for  clients 
that  send  5  probes  and  APs  with  500  keys.  The  public  key  protocol  spends  most  of  its 
time  in  the  first  two  phases,  since  it  must  process  most  public  key  encryptions,  decryptions, 
and  signature  checks  here.  These  operations  are  two  orders  of  magnitude  slower  than  the 
symmetric  key  analogs.  Nonetheless,  the  symmetric  key  protocol  still  spends  significant 
time  in  the  probing  phase,  because  when  the  AP  first  receives  a  probe,  it  may  try  to  verify 
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Figure  3.8:  Link  setup  time  as  the  number  of  probes  eaeh  elient  sends  varies.  The  AP  has 
500  keys.  Error  bars  indicate  one  standard  deviation. 


probing  openauth  associate  wpa-key 

total 

public  key 

886.1 

895.2 

146.2 

NA 

1927.6 

symmetric  key 

120.2 

8.6 

6.9 

NA 

135.6 

tryst 

3.3 

5.1 

6.2 

NA 

14.5 

wifi-open 

1.4 

1.5 

2.2 

NA 

5.1 

wifi-wpa 

0.1 

6.9 

0.8 

57.5 

65.3 

Table  3.3:  Breakdown  of  link  setup  time  for  a  client  that  probes  for  5  different  networks 
and  an  AP  with  500  keys.  Times  are  in  milliseconds.  Each  phase  corresponds  to  re¬ 
quest/response  messages  in  Eigure  3.1,  except  wpa-key,  which  involves  2  round  trips  after 
association  to  derive  session  keys  in  wifi-wpa. 


the  MAC  with  all  its  keys.  Subsequent  phases  are  faster  because  both  the  client  and  the 
AP  re-sort  their  keys  in  MRU  order,  so  the  expected  number  of  keys  they  must  try  before 
finding  the  right  one  decreases  appreciably. 

Tryst  has  similar  performance  to  the  symmetric  key  protocol  during  the  last  three 
phases  because  the  number  of  cryptographic  operations  is  identical.  However,  the  first 
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Figure  3.9:  CDF  of  background  probe  and  authentication  messages  observed  each  second 
where  discovery  was  taking  place  in  each  of  three  802.11  traces.  We  only  count  times 
when  there  was  at  least  one  probe  (i.e.,  times  when  discovery  was  taking  place). 
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phase  is  much  faster  because  the  AP  looks  up  the  address  in  a  hash  table  to  determine 
which  key  to  use  to  verify  the  message.  The  open  authentication  and  association  phases 
take  slightly  longer  because  they  involve  computing  the  initial  w  Shroud  addresses.  Even 
when  performing  these  operations,  in  addition  to  standard  802.11  processing,  the  time  it 
takes  for  SlyFi  using  Tryst  to  setup  a  link  is  less  than  10  ms  more  than  that  of  wifi-open, 
which  provides  no  authentication  or  confidentiality.  Moreover,  it  is  faster  than  wifi-wpa.’ 

Note  that  if  a  client  did  not  know  the  particular  wireless  frequency  a  network  was 
located  on,  it  would  spend  more  time  in  the  probing  phase  because  it  would  have  to  wait 
on  each  channel  to  see  if  a  probe  response  arrives.  This  waiting  time  is  configured  to  be 
20-200  ms  in  802. 1 1 . 

Background  probing  traffic.  The  previous  experiments  assumed  no  ambient  background 
traffic  during  the  link  setup  process.  However,  due  to  the  ad  hoc  nature  of  real  wireless 
deployments,  stations  and  APs  often  overhear  messages  that  are  not  destined  for  them.  For 

^We  note  that  wifi-wpa  incurs  an  unnecessary  delay  in  the  open  authentication  phase,  but  since  the  bulk 
of  the  time  is  spent  in  wpa-key  for  key  computation  and  exchange,  removing  this  delay  would  not  change 
the  ranking  of  the  total  link  setup  times. 
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Figure  3.10:  Percentage  of  100  link  setup  attempts  that  fail  to  complete  within  30  seconds 
as  we  vary  the  rate  of  background  probe  traffic  not  destined  for  the  target  AP.  The  client 
probes  for  one  AP  and  the  AP  has  500  keys. 


example,  Figure  3.9  shows  the  rate  of  probe  requests,  responses,  and  authentication  mes¬ 
sages  observed  by  one  monitoring  point. ^  Although  the  ambient  message  rate  is  generally 
fairly  low,  there  are  times  when  the  rate  is  over  100  messages  per  second,  due  to  many 
clients  performing  discovery  at  once.  Thus,  it  is  crucial  that  clients  and  APs  be  able  to 
discard  these  messages  quickly. 

To  evaluate  how  well  SlyFi  can  manage  background  probe  and  authentication  mes¬ 
sages,  we  examine  a  client’s  link  setup  time  as  a  function  of  such  traffic.  To  do  this,  we 
introduce  a  third  machine  that  sends  background  messages  at  a  specified  rate  destined  nei¬ 
ther  for  the  client  or  the  AP.  These  background  messages  are  encapsulated  in  the  protocols 
we  compare,  but  we  precompute  them  so  that  their  generation  is  able  to  maintain  the  spec¬ 
ified  rate.  Each  protocol  queues  up  to  10  messages  (drop  tail)  if  it  is  busy  processing  and 
each  client  request  is  retransmitted  once  per  second.  We  consider  a  link  setup  attempt  to 
fail  if  it  does  not  complete  in  30  seconds.  The  client  probes  once  for  an  AP  with  500  keys.^ 

®The  UCSD  trace  merged  observations  from  multiple  monitoring  points,  so  it  observes  more  traffic  at 
any  given  time.  The  OSDI  trace  contains  more  users  than  the  SIGCOMM  trace  and  thus  observed  a  higher 
rate  of  traffic. 

^Note  that  in  this  experiment,  the  client  and  AP  drivers  ran  in  user  level,  rather  than  in  the  kernel,  be- 
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Figure  3.11:  Link  setup  time  for  successful  attempts  as  we  vary  the  rate  of  background 
probe  traffic  not  destined  for  the  target  AP.  Error  bars  indicate  one  standard  deviation. 


Figure  3.10  shows  the  percentage  of  link  setup  attempts  that  failed.  Due  to  the  pro¬ 
cessing  required  by  the  public  key  and  symmetric  key  protocols  in  order  to  determine 
whether  a  message  is  destined  for  the  receiver,  each  begins  to  fail  when  the  background 
message  rate  grows.  No  attempts  fail  when  using  Tryst  or  wifi-open.  We  omit  the  line  for 
wifi-wpa  because  its  message  retry  behavior  is  different.  Figure  3.11  shows  the  link  setup 
times  for  the  attempts  that  succeeded.  Note  that  while  the  symmetric  key  protocol  is  able 
to  cope  with  message  rates  of  up  to  100  messages/second  before  it  begins  to  fail,  its  link 
setup  times  grow  to  several  seconds,  and  impact  perceived  performance,  even  when  the 
rate  is  50  messages/second. 

Contention  for  the  medium  causes  Tryst,  wifi-open,  and  wifi-wpa  to  each  have  link 
setup  times  that  grow  slightly  as  the  background  message  rate  increases,  but  their  scaling 
behavior  is  gradual  and  roughly  consistent.  Tryst’s  ability  to  discard  background  messages 
quickly  enables  it  to  scale  gracefully.  This  property  is  important  not  only  for  dealing  with 
ambient  discovery  traffic,  but  also  for  mitigating  the  impact  of  malicious  denial  of  service 
attacks.  With  the  public  key  and  symmetric  key  protocols,  a  malicious  device  only  needs 

cause  when  the  straw  man  protocols  become  overloaded  with  message  processing,  the  Linux  kernel  became 
unresponsive  to  experimental  commands.  This  imposes  a  slight  overhead  on  message  processing,  but  is 
insubstantial  compared  to  each  protocol’s  relative  performance. 
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#  keys 

1  10 

50 

100 

500 

1000 

10,000 

time  (msec) 

0.08  0.49 

2.3 

4.7 

24 

47 

800 

Table  3.4:  The  mean  time  to  update  Tryst  addresses  for  a  single  time  interval  as  we  vary 
the  number  of  keys. 


to  send  a  small  number  of  messages  to  prevent  a  client  from  setting  up  a  link. 

Address  update  time.  At  the  beginning  of  each  time  interval,  a  Tryst  node  precomputes 
the  message  addresses  it  expects  to  receive  to  enable  quick  message  filtering.  Table  3.4 
shows  the  time  it  takes  to  compute  these  addresses  and  update  the  hash  table  as  we  increase 
the  number  of  keys  a  device  holds.  A  node  computes  two  addresses  per  time  interval,  per 
key  (one  for  probes  and  one  for  authentication  messages).  Clients,  which  are  unlikely 
to  have  more  than  100  keys,  would  spend  only  a  few  milliseconds  each  time  interval  to 
update  addresses,  and  time  intervals  would  likely  be  at  least  several  minutes.  Even  APs 
with  10,000  clients  would  spend  less  than  1  second. 


3.7.4  Data  Transport  Performance 

We  now  examine  how  well  Shroud  performs  at  delivering  data  packets.  We  begin  with  a 
description  of  micro-benchmarks  that  break  down  how  long  Shroud  takes  to  send,  filter, 
and  receive  packets.  Then  we  present  an  analysis  of  packet  delivery  latency  and  throughput 
when  a  SlyFi  client  and  AP  are  communicating  in  isolation.  Finally,  we  look  at  perfor¬ 
mance  in  the  face  of  background  traffic,  and  present  results  describing  achievable  through¬ 
put  both  as  the  number  of  clients  managed  by  the  AP  and  the  amount  of  competing  traffic 
varies. 

Simulated  hardware  encryption.  Shroud’s  cryptography  operations  are  implemented  in 
software,  which  adversely  affects  performance.  To  understand  how  Shroud  would  perform 
with  hardware  support,  we  simulate  the  processing  times  of  that  hardware.  As  a  result,  we 
provide  measurements  both  for  the  software-only  version,  shroud-sw,  as  well  as  for  the 
version  with  hardware  simulation,  shroud-hw. 

Since  both  wifi-wpa  and  Shroud  use  AES  to  encrypt  and  MAC  packets,  we  use  wifi- 
wpa’s  processing  times  as  an  estimate  for  shroud-hw.^°  We  estimate  wifi-wpa’s  cryp- 

'®wifi-wpa  uses  AES  counter  mode  for  payload  encryption  and  AES-CBC  for  MAC  computation,  while 
Shroud  uses  AES-CBC  mode  for  payload  encryption  and  CMAC  (a  relative  of  AES-CBC  mode)  for  the 
MAC.  Counter  mode  is  parallelizable,  while  AES-CBC  is  not. 
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send 

sw  hw 

filter 

sw  hw 

receive 

sw  hw 

update  addrs 
(max  message  loss) 

15  14 

NA  NA 

2047  2003  (50) 

(no  message  loss) 

15  14 

NA  NA 

119  117  (1) 

process  etext 

951  16 

NA  NA 

1541  16 

process  emac 

740  16 

NA  NA 

740  16 

Shroud  total 

1821  120 

32  32 

3290  290 

Click  total 

1913  215 

144  144 

3402  407 

Table  3.5:  Breakdown  of  processing  times  (see  Section  3.3.4)  for  1500  byte  packets  for 
shroud-sw  (sw)  and  shroud-hw  (hw).  All  times  are  in  microseconds.  Numbers  in  paren¬ 
theses  are  numbers  of  address  computations. 


tographic  processing  time  (including  I/O)  as  the  difference  in  round  trip  ping  delays  be¬ 
tween  wifi-wpa  and  wifi-open-driver.  Measurements  suggest  the  time  to  encrypt  a  1500 
byte  ICMP  packet  is  ~16  usee  and  the  time  to  encrypt  a  payload-free  packet  is  ~14  usee. 
I/O  overhead  dominates,  but  there  is  a  small  linear  scaling  factor  as  the  packet  size  in¬ 
creases.  Neither  encryption  nor  MAC  computation  are  parallelizable  in  Shroud,  whereas 
CCMP’s  encryption  may  be  parallelized  in  hardware.  Thus,  we  conservatively  estimate 
that  shroud-hw  would  take  14  usee  to  encrypt  a  pair  of  addresses  and  32  usee  to  encrypt 
and  MAC  packet  payloads.  To  simulate  these  times,  we  modify  our  code  to  idle-wait  for 
these  times  instead  of  computing  the  cryptographic  operations  in  software.  We  note  that 
shroud-hw  still  includes  the  actual  software  processing  time  of  all  non- AES  operations. 

Micro-benchmarks.  Table  3.5  breaks  down  the  time  to  send,  filter,  and  receive  Shroud 
messages.  On  a  busy  network,  a  packet  received  by  a  client  is  often  intended  for  someone 
else,  so  filtering  packets  quickly  is  imperative.  The  filter  column  shows  that  shroud-hw’s 
filtering  time  (32  usees)  is  much  faster  than  the  theoretical  minimum  packet  transmission 
time  in  802. 1  la  for  a  1500  byte  packet  (~225  usees),  suggesting  that  a  receiver  could  filter 
packets  faster  than  the  medium  could  supply  them. 

Sender-side  processing  of  a  1500  byte  packet,  shown  in  the  send  column  (215  usee), 
also  edges  out  the  time  to  transmit  it,  and  thus,  shroud-hw  should  be  capable  of  support¬ 
ing  802.1  la’s  line  speed.  Receiver-side  processing  (the  receive  column)  from  the  radio 
takes  407  usee,  which  is  greater  than  the  theoretical  time  to  transmit,  but  still  reasonable. 
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Figure  3.12:  Throughput  comparison  of  UDP  packets  when  transmitting  at  54  Mbps  for 
30  seconds.  Each  point  is  the  average  of  50  runs. 


since  802.11  rates  in  practice  are  much  slower  (e.g.,  see  Figure  3.12).  When  packets  are 
lost,  additional  address  computations  must  be  performed  after  a  reception.  A  reception 
following  the  maximum  49  packet  burst  loss  (for  w  =  50)  requires  Shroud  to  compute  and 
update  50  new  addresses.  This  takes  2003  usee  compared  to  1 17  usee  for  a  single  address 
update  (the  case  with  no  loss). 

The  cryptographic  operations  are  much  slower  when  implemented  in  software  than 
they  are  in  hardware,  and  thus  the  performance  of  shroud-sw  is  significantly  below  line 
speed.  Regardless,  we  present  these  results  to  characterize  our  proof-of-concept  imple¬ 
mentation  that  can  be  used  today  to  protect  privacy.  Obviously,  an  engineering  effort  is 
required  to  make  use  of  hardware  cryptography. 


Throughput  and  latency.  Figure  3.12  shows  achievable  throughput  for  shroud-hw, 
shroud-sw,  wifi-open,  and  wifi-open-driver,  measured  using  iperf .  Shroud  is  imple¬ 
mented  in  Click,  so  wifi-open  provides  a  baseline  against  which  to  evaluate  its  perfor¬ 
mance.  While  wifi-open  (802.11  implemented  in  Click)  performs  worse  than  wifi-open- 
driver  (the  native  driver  implementation),  the  throughput  degradation  of  shroud-hw  is 
comparable  to  wifi-wpa  relative  to  their  respective  baselines.  Optimizing  wifi-open  is  a 
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Figure  3.13:  Comparison  of  round  trip  times  of  ICMP  ping  messages  for  variously  sized 
packets.  Each  point  is  the  average  of  1000  pings;  pings  that  experienced  link-layer  packet 
loss,  or  re -keying  delays  (in  the  case  of  wifi-wpa),  were  removed. 


subject  for  future  work.  When  sending  1500  byte  packets,  shroud-hw  degrades  wifi-open 
performance  by  only  1.44  Mbps  compared  to  the  0.71  Mbps  degradation  from  running 
wifi-wpa.  Since  both  Shroud  and  wifi-wpa  use  some  non-parallelizable  cryptographic 
operations,  the  relative  performance  degradation  increases  with  packet  size,  shroud- 
SW  experiences  a  much  larger  drop  in  throughput,  but  still  provides  a  functional  link 
(3.73  Mbps). 

Figure  3.13  presents  round  trip  time  measurements  using  ping.  For  1500  byte  pack¬ 
ets,  two  packet  payload  encryptions  and  decryptions  take  ~60  usee  in  wifi-wpa  and  ~  130  usee 
in  shroud-hw;  the  extra  time  is  due  to  address  encryption.  We  believe  the  sudden  marked 
increase  in  shroud-sw  between  300  and  400  byte  packets  is  due  to  an  inefficiency  in  the 
Click  runtime.'^ 

Background  traffic.  Shroud’s  design  is  motivated  by  the  requirement  that  background 
traffic  must  be  filtered  efficiently.  To  study  how  well  Shroud  filters  packets,  we  run  an 
experiment  in  which  a  client,  Ci,  sends  packets  as  fast  as  possible  to  an  access  point,  APi. 

^ '  Short  packets  get  through  the  Click  data  path  without  a  context  switch  from  the  OS,  while  longer  packets 
do  not. 
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Figure  3.14:  Effect  of  association  set  size  on  achievable  throughput  when  exposed  to 
5  Mbps  of  background  traffic  for  Shroud’s  and  armknecht’s  software  implementation 
and  hardware  simulation.  Each  run  is  30  seconds;  each  point  is  the  average  of  50  runs. 


Nearby,  we  generate  background  traffic  by  having  another  client,  C2  send  traffic  to  another 
AP,  AP2.  We  measure  the  throughput  at  APi.  Since  the  number  of  keys  APi  manages  (i.e., 
number  of  associations)  and  the  amount  of  background  traffic  both  affect  throughput,  we 
vary  both  independently. 

Eigure  3.14  shows  throughput  measured  at  Ci  for  both  the  software  implementation 
and  hardware  simulation  of  Shroud  and  armknecht,  as  the  number  of  keys  at  APi  is 
varied.  Since  Shroud  can  filter  background  packets  with  just  a  hash  table  lookup,  its 
achievable  throughput  is  independent  of  the  number  of  keys.  However,  armknecht’s  per¬ 
formance  gets  progressively  worse  as  the  number  of  keys  increases.  This  is  because  clients 
and  APs  running  armknecht  must  try  every  key  they  have  before  discarding  background 
packets. 

Eigure  3.15,  which  shows  throughput  achieved  as  a  function  of  the  competing  flow 
rate,  depicts  a  similar  effect.  As  the  amount  of  background  traffic  increases,  through¬ 
put  decreases  for  both  Shroud  and  armknecht,  but  considerably  more  so  for  armknecht. 
E.g.,  with  10  Mbps  of  background  traffic,  throughput  is  31%  lower  for  shroud-hw  than 
it  is  with  no  competing  traffic,  but  it  is  72%  lower  for  armknecht-hw.  This  reduction  re¬ 
sults  from  a  combination  of  two  effects:  Eirst,  background  traffic  reduces  the  availability 
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Figure  3.15:  Effect  of  background  traffic  on  achievable  throughput  from  a  client  to  an 
AP.  The  APs  association  set  includes  50  keys.  Each  run  is  30  seconds;  each  point  is  the 
average  of  50  runs. 


of  the  channel,  as  is  evident  in  the  throughput  reduction  (26%)  of  our  baseline,  wifi-open, 
which  performs  no  cryptographic  operations.  This  affects  Shroud  and  armknecht  simi¬ 
larly.  Second,  background  traffic  requires  work  to  filter,  which  is  much  more  expensive  in 
armknecht. 


3.8  Summary  and  Discussion 

This  chapter  presented  the  design  and  evaluation  of  SlyEi,  an  identifier-free  802.11  link 
layer  that  obfuscates  all  transmitted  bits,  including  addresses.  The  primary  contribution 
of  SlyEi  is  the  development  of  two  mechanisms.  Tryst  and  Shroud,  that  can  perform  this 
obfuscation  on  existing  link  layer  protocols  without  sacrificing  efficiency  or  important 
protocol  functions.  Eor  example,  SlyEi  can  still  perform  efficient  discovery,  link  establish¬ 
ment,  and  data  transport,  and  higher  layer  name  binding.  Our  evaluation  showed  that  SlyEi 
performs  comparably  to  WPA  and  performs  substantially  better  than  previously  proposed 
techniques. 
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3.8.1  Discussion 


We  note  that  there  are  four  important  areas  that  merit  further  attention  when  SlyFi-like  pro- 
toeols  are  deployed  more  widely:  private  bootstrapping,  large-seale  broadeast  diseovery, 
wireless  fault  diagnosis,  and  side-ehannel  eoneealment  in  praetiee. 

Bootstrapping  shared  keys  remains  a  manual  process.  In  both  existing  seeure  wireless 
protoeols  and  in  SlyFi,  an  important  ehallenge  is  how  to  bootstrap  the  symmetrie  or  publie 
keys  that  are  neeessary  before  two  deviees  are  able  to  rendezvous  and  authentieate  eaeh 
other  for  the  first  time.  Existing  bootstrapping  teehniques  for  key  establishment  typieally 
fall  into  the  eategory  of  pairing  [152],  i.e.,  having  users  of  the  deviees  use  an  out-of-band 
ehannel  to  exehange  seerets.  In  many  eireumstanees  these  teehniques  are  either  eumber- 
some  and  hinder  usability  or  are  inapplieable  beeause  no  sueh  out-of-band  ehannel  exists 
(e.g.,  if  the  user  ean  not  physieally  identify  the  other  deviee).  Therefore,  it  would  be  useful 
to  develop  automated  key  establishment  teehniques  that  do  not  require  user  intervention. 
We  diseuss  some  initial  direetions  in  this  area  in  Chapter  5. 

SlyFi  does  not  yet  support  efficient  large-scale  broadcast  discovery.  We  deseribed  in 
Seetion  3.4. 1  how  Tryst  ean  use  a  single  paeket  to  diseover  multiple  parties,  but  the  size  of 
this  paeket  seales  linearly  with  the  number  of  parties.  Atypieal  elients  that  want  to  diseover 
the  presenee  of  hundreds  or  thousands  of  serviees  eonfidentially  will  ineur  substantial 
message  overhead  with  either  protoeol  deseribed  above.  To  reduee  this  overhead  in  a 
presenee  sharing  applieation,  Cox  et  al.  [46]  propose  sharing  a  single  key  with  eliques 
of  mutually  trusting  friends.  However,  this  makes  ehanging  trust  relationships  diffieult 
beeause  it  requires  global  agreement  among  the  members  of  a  elique.  This  is  partieularly 
diffieult  for  mobile  deviees  that  are  often  offline. 

One  attraetive  option  is  a  elass  of  eneryption  protoeols  that  enable  a  sender  to  broadeast 
a  message  that  has  size  sub-linear  in  the  number  of  authorized  reeipients,  but  ean  still  only 
be  deerypted  by  those  reeipients  [55,  119].  Both  publie  and  symmetrie  key  variants  exist. 
These  protoeols  are  made  possible  by  the  additional  assumption  that  no  more  than  m 
revoked  reeeivers  eollude  or  no  more  than  r  reeeivers  are  ever  revoked.  However,  these 
protoeols  require  key  state  and  message  overhead  that  are  both  super-linear  in  either  m  or 
r,  and  therefore  would  only  be  more  effleient  when  the  number  of  serviees  a  elient  wants 
to  diseover  is  larger.  Moreover,  their  eurrent  instantiations  reveal  the  sender’s  identity  and 
relationships  (e.g.,  beeause  they  inelude  the  list  of  revoked  deviees).  It  is  an  open  problem 
whether  they  ean  be  made  private  [17]. 

Alternatively,  one  eould  reduee  the  number  of  serviees  a  elient  attempts  to  diseover 
by  ruling  out  serviees  that  are  unlikely  to  be  present  based  on  eontext  and  loeation  (e.g.. 
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using  GPS).  Nonetheless,  it  is  important  that  using  context  does  not  inadvertently  expose 
identity  or  relationships  (e.g.,  discovery  in  different  contexts  should  not  noticeably  change 
the  number  of  discovery  messages  sent,  lest  message  volume  be  used  as  a  fingerprint). 

SlyFi  may  require  novel  fault  diagnosis  techniques.  By  concealing  all  bits  in  trans¬ 
mitted  messages,  SlyFi  potentially  makes  diagnosing  faults  in  wireless  networks  more 
difficult  because  any  eavesdropping  device,  including  those  used  for  network  monitoring, 
requires  the  appropriate  shared  keys  in  order  to  interpret  any  packets  on  the  network.  For 
example,  in  some  scenarios,  bootstrapped  keys  may  need  to  be  entered  manually  into  the 
devices  by  humans,  which  is  an  error-prone  process.  Distinguishing  an  erroneous  en¬ 
try  from  a  broken  network  is  more  difficult  with  SlyFi  because,  from  an  eavesdropper’s 
perspective,  the  pattern  of  packets  observed  is  not  easily  distinguishable.  There  is  a  funda¬ 
mental  trade-off  between  the  ease  of  diagnosing  configuration  errors  using  eavesdropping 
equipment  and  the  amount  of  information  that  is  concealed  from  malicious  eavesdroppers. 
The  appropriate  trade-off  to  make  will  become  more  apparent  when  SlyFi-like  protocols 
are  used  more  often  in  practice. 

SlyFi  does  not  always  conceal  all  side-channels.  SlyFi  mitigates  the  effectiveness  of 
side-channels,  such  as  packet  sizes  and  timing,  because  different  message  streams  overlap 
in  practice,  making  it  difficult  to  distinguish  them.  Initial  work  by  Bauer  et  al.  [18,  19] 
suggests  that  this  traffic  mixing  does  make  some  known  side-channel  attacks  more  diffi¬ 
cult  to  carry  out,  even  if  physical  layer  information  such  as  RSSI,  is  taken  into  account. 
Nonetheless,  a  more  thorough  analysis  of  how  accurately  eavesdroppers  may  still  be  able 
to  detect  users’  fingerprints  would  shed  light  on  whether  additional  countermeasures,  such 
as  cover  traffic,  are  needed  in  practice.  In  addition,  we  still  lack  an  empirical  understand¬ 
ing  of  how  often  different  traffic  streams  overlap  in  less  dense  environments,  such  as  small 
hotspots  —  we  only  studied  dense  wireless  environments  such  as  conferences  and  office 
buildings.  If  there  are  not  very  many  streams  overlap  in  such  environments  or  if  they  are 
easily  distinguishable  using  physical  layer  information,  then  additional  countermeasures 
against  side-channel  attacks  will  be  required.  Nonetheless,  we  note  that  all  wireless  en¬ 
vironments  are  becoming  denser  due  to  the  continued  proliferation  of  wireless  devices. 
Thus,  in  the  near  future,  the  qualitative  aspects  of  mixing  wireless  traffic,  rather  than  the 
quantity  of  wireless  streams,  may  be  more  important  to  study. 
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Chapter  4 

Mitigating  Threats  from  Crowd-sourced 
Location-based  Systems 


SlyFi  conceals  identifiers  from  eavesdroppers  during  the  proeesses  of  rendezvous  and 
eommunieation.  However,  users  may  still  need  to  report  loeation  information  and  their 
identities  to  LBSes.  In  partieular,  to  loeate  publie  Wi-Fi  APs  to  use  in  the  first  plaee  (e.g., 
when  visiting  a  new  area),  users  may  have  to  query  a  hotspot  direetory  service  such  as  Ji- 
Wire  [85].  Hotspot  APs,  of  course,  are  immobile  and  publie,  so  they  are  unlikely  to  desire 
location  privacy — indeed,  most  want  to  be  found  so  users  will  pay  to  use  them.  However, 
the  users  that  use  them  likely  do. 

Although  the  loeation  masking  techniques  deseribed  in  Seetion  1.3  ean  be  used  to 
obseure  a  user’s  loeation  in  queries  to  hotspot  directories,  many  of  these  directories  rely 
on  user  reeorded  reports  in  order  to  populate  them  (e.g.,  Hotspotr).  Furthermore,  users 
report  that  some  APs  bloek  applieations  [174]  and  have  poorer  than  advertised  end-to- 
end  performanee  [51],  so  selecting  the  best  eommercial  AP  is  not  always  straightforward. 
Thus,  it  may  be  useful  for  these  direetories  to  incorporate  user-submitted  measurements  on 
APs  as  a  crowd-sourced  LBS.  This  would  enable  users  to  evaluate  eommercial  APs  before 
paying  for  access. 

In  this  ehapter  we  answer  two  primary  questions: 

1.  Are  crowd-sourced  hotspot  directory  services  useful?  That  is,  are  such  directory 
services  even  neeessary? 

2.  How  ean  we  build  them  so  that  users’  loeation  privacy  is  respected,  yet  fraudulent 
reports  are  limited? 
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We  address  the  first  question  by  presenting  the  first  measurement  study  of  commercial 
APs  in  hotspot  settings.  Previous  war-driving  studies  [71,  122]  performed  Wi-Fi  mea¬ 
surements  from  streets  or  sidewalks,  whereas  we  measure  APs  from  the  perspective  of  a 
typical  Wi-Fi  user  who  is  inside  an  establishment.  Our  study  examines  the  end-to-end  per¬ 
formance  and  application  support  of  all  visible  APs  at  13  hotspot  locations  in  Seattle  over 
the  course  of  1  week.  We  find  that  there  is  indeed  a  wide  range  of  AP  performance  even 
among  APs  very  close  to  each  other.  Since  there  is  currently  no  way  for  a  user  to  determine 
which  AP  would  be  best  to  run  his  applications  before  paying  for  access,  a  crowd-sourced 
hotspot  directory  that  collected  performance  measurements  from  users  would  indeed  be 
useful  for  AP  location  and  selection. 

To  address  the  second  question,  we  present  Wifi-Reports,  a  collaborative  service  that 
provides  clients  with  historical  information  to  improve  AP  selection.  Wifi-Reports  has 
two  main  uses:  First,  it  provides  users  with  a  hotspot  database  similar  to  JiWire  but  where 
APs  are  annotated  with  performance  information.  Second,  it  enables  users  to  more  effec¬ 
tively  select  among  APs  visible  at  a  particular  location.  Wireless  clients  that  participate  in 
Wifi-Reports  automatically  submit  reports  on  the  APs  that  they  use.  Reports  include  met¬ 
rics  such  as  estimated  back-haul  capacity,  ports  blocked,  and  connectivity  failures.  Using 
submitted  reports,  the  service  generates  summary  statistics  for  each  AP  to  predict  its  end- 
to-end  performance.  Obtaining  accurate  user-submitted  reports  poses  two  challenges: 

(1)  Location  privacy:  As  we  have  already  suggested,  a  user  should  not  have  to  reveal 
that  he  used  an  AP  to  report  on  it.  Otherwise  he  would  implicitly  reveal  a  location  that  he 
visits.  Users  may  be  reluctant  to  participate  in  Wifi-Reports  if  their  identities  can  be  linked 
to  their  reports.  At  the  same  time,  however,  a  few  users  should  not  be  able  to  significantly 
skew  an  AP’s  summary  statistics  because  some  may  have  an  incentive  to  submit  fraudulent 
reports,  e.g.,  to  promote  APs  that  they  own.  One  way  to  meet  these  conflicting  goals 
is  to  assume  the  existence  of  a  trusted  authority  that  is  permitted  to  link  users  to  their 
reports  in  order  to  detect  fraud  (e.g.,  in  the  way  that  eBay  manages  user  reputations). 
For  good  reason,  users,  privacy  groups,  and  governments  are  becoming  increasingly  wary 
about  malicious  or  accidental  disclosures  of  databases  that  can  track  large  numbers  of 
people  [168].  Therefore,  we  present  a  report  submission  protocol  that  tolerates  a  few 
misbehaving  users  and  does  not  require  the  disclosure  of  location  related  information  to 
anyone,  including  the  Wifi-Reports  service.  Our  protocol  leverages  blind  signatures  to 
ensure  that  the  service  can  regulate  the  number  of  reports  that  each  user  submits,  but 
cannot  distinguish  one  user’s  reports  from  another’s. 

(2)  Location  context:  Physical  obstructions  and  the  distance  between  a  client  and  an  AP 
affect  the  quality  of  the  wireless  channel.  Therefore,  we  must  take  location  context  into  ac¬ 
count  when  estimating  AP  performance  or  our  estimates  will  not  be  accurate.  We  describe 
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how  measurements  can  be  categorized  by  the  different  wireless  channel  conditions  under 
which  they  were  performed.  We  also  describe  how  to  index  and  retrieve  reports  based  on 
location  without  requiring  additional  equipment  such  as  GPS. 

We  have  implemented  the  key  components  of  Wifi-Reports  and  used  our  measure¬ 
ment  study  to  simulate  how  well  it  would  work.  Our  results  suggest  that  even  if  a  user  is 
only  selecting  among  APs  at  a  single  location,  Wifi-Reports  performs  close  to  optimal  in 
more  cases  than  existing  techniques  such  as  best-signal-strength  and  best-open- AP  [122] 
because  it  provides  information  on  commercial  APs  that  cannot  be  tested  beforehand. 
We  show  that  Wifi-Reports’  summary  statistics  predict  performance  accurately  enough  to 
make  correct  relative  comparisons  between  different  APs,  despite  performance  variability 
due  to  competing  traffic.  For  example,  it  predicts  AP  throughput  and  response  time  to 
within  a  factor  of  2  at  least  75%  of  the  time.  Since  different  APs’  median  throughputs 
and  response  times  differ  by  up  to  50  x  and  10  x,  respectively,  this  prediction  accuracy 
enables  Wifi-Reports  to  select  the  best  AP  more  often  in  more  locations  than  any  previous 
AP  selection  approach.  Moreover,  unlike  previous  AP  selection  approaches,  Wifi-Reports 
enables  users  to  examine  the  characteristics  of  APs  that  not  in  radio  range,  which  is  useful 
when  users  are  mobile. 

Although  we  presented  our  reporting  protocol  in  the  context  of  a  hotspot  directory  ser¬ 
vice,  it  is  applicable  to  crowd-sourced  recommender  systems  more  generally.  Nonetheless, 
we  note  that  there  are  two  important  limitations.  First,  the  protocol’s  practicality  is  depen¬ 
dent  on  the  ability  to  group  items  being  voted  on  into  subsets  that  are  reasonably  small 
and  not  revealing.  Second,  the  protocol  can  not  be  applied  when  collaborative  filtering  is 
required.  We  discuss  these  limitations  in  greater  detail  in  Section  4.7. 

Chapter  outline.  Section  4.1  presents  the  results  of  our  measurement  study.  Section  4.2 
presents  an  overview  of  Wifi-Reports’  design.  Section  4.3  describes  how  it  preserves 
privacy  and  mitigate  fraud.  Section  4.4  describes  how  it  distinguish  client  locations.  Sec¬ 
tion  4.5  presents  an  evaluation  of  Wifi-Reports.  Section  4.6  describes  protocols  similar  to 
Wifi-Reports’  reporting  protocol  and  Section  4.7  concludes  this  chapter. 


4.1  Measurement  Study 

We  conducted  a  measurement  study  to  determine  whether  existing  AP  selection  algorithms 
are  sufficient  to  choose  an  AP  that  meets  a  user’s  needs.  We  sought  answers  to  three 
questions  that  illustrate  whether  this  choice  is  obvious  and  whether  it  can  be  improved 
with  Wifi-Reports. 
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Diversity.  Is  there  diversity  in  terms  of  end-to-end  performance  and  application  support 
of  different  hotspots’  APs?  The  more  diversity,  the  more  likely  a  user  will  choose  a  hotspot 
with  substantially  suboptimal  performance  when  selecting  randomly  from  a  hotspot  direc¬ 
tory. 

Rankability.  Is  the  best  choice  of  AP  at  a  particular  location  always  obvious?  If  the  best 
APs  do  not  have  any  observable  traits  in  common,  then  AP  selection  algorithms  that  use 
the  same  metric  to  rank  APs  at  all  locations  will  sometimes  pick  suboptimal  APs. 

Predictability.  Is  end-to-end  performance  predictable  enough  so  that  historical  informa¬ 
tion  would  be  useful? 

Our  study  examined  hotspots  around  University  Avenue,  Seattle,  WA,  near  the  Uni¬ 
versity  of  Washington.  We  believe  this  area  is  representative  of  commercial  districts  with 
multiple  Wi-Fi  service  providers.  It  is  less  likely  to  be  representative  of  areas  that  only 
have  a  single  Wi-Fi  service  provider,  such  as  in  many  airports.  However,  since  users 
don’t  have  a  choice  of  AP  providers  in  those  environments,  selecting  a  provider  to  use  is 
straightforward.  Wifi-Reports  could,  however,  still  help  a  user  decide  if  purchasing  access 
is  worthwhile.  Figure  4.1  shows  the  hotspot  locations  where  we  performed  measurements, 
which  included  those  listed  in  JiWire’s  database  and  some  additional  sites  known  to  us. 

All  locations  are  single-room  coffee  or  tea  shops.  Most  APs  we  measured  are  not  open. 
In  addition  to  each  hotspot’s  official  AP,  the  APs  of  hotspots  nearby  are  also  usually  visi¬ 
ble.  APs  of  the  free  public  seattlewifi  network  are  sometimes  visible  at  all  locations.  APs 
belonging  to  the  University  of  Washington  network  are  sometimes  visible  due  to  prox¬ 
imity  to  campus  buildings,  though  these  were  never  the  best  performing  at  any  location. 
Our  study  offers  a  lower  bound  on  the  number  and  diversity  of  APs,  as  more  may  become 
available. 


4.1.1  Setup 

Infrastructure.  To  emulate  a  typical  user  of  Wifi-Reports,  we  collected  measurements 
with  a  commodity  laptop  with  an  Atheros  802.1  Ib/g  miniPCI  card  attached  to  the  laptop’s 
internal  antennas.  We  implemented  a  custom  wireless  network  manager  for  associating  to 
APs  and  performing  measurements  after  association.  Our  implementation  is  based  on  the 
Mark-and-Sweep  war  driving  tool  [71]. 

Methodology.  During  each  measurement  trial  at  a  location,  we  emulate  a  typical  connec¬ 
tion  attempt  by  scanning  for  visible  APs.  We  then  attempt  to  associate  and  authenticate 
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Figure  4.1:  Measured  hotspot  loeations  near  University  Avenue,  Seattle,  WA 


with  eaeh  AP  found  (identified  by  its  unique  BSSID).  If  sueeessful,  we  run  our  battery  of 
measurement  tests  before  moving  on  to  the  next  AP.  We  manually  obtain  authentieation 
credentials,  if  necessary  (e.g.,  through  a  purchase).  Since  many  Wi-Fi  drivers  do  not  list 
APs  with  low  signal-to-noise  (SNR)  ratios,  we  only  attempt  to  connect  to  APs  when  they 
appear  with  an  SNR  >  10  dB.^ 

We  performed  measurements  at  typical  seating  locations  in  each  hotspot.  Although 
the  exact  same  location  was  not  used  for  all  measurements  in  a  hotspot.  Section  4.4  shows 
how  well  we  can  distinguish  performance  at  different  locations. 


^One  physical  AP  at  each  Starbucks  advertised  two  virtual  APs.  Since  we  did  not  find  any  service 
differentiation  between  these  virtual  APs  after  login,  we  only  include  one  of  them  in  our  study.  They  exist 
because  Starbucks  hotspots  are  migrating  from  T-Mobile  to  AT&T  Wi-Fi. 
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Figure  4.2:  (a)  The  success  rate  of  different  APs  (i.e.,  how  often  we  could  connect 
and  access  the  Internet  when  each  AP  was  visible).  Each  point  represents  one  AP 
visible  at  each  location,  (b)  A  box-plot  of  the  measured  TCP  download  through¬ 
put  through  each  APs.  Note  the  logarithmic  scale,  (c)  A  box-plot  of  the  time  to 
fetch  http  :  /  /www .  google  .  com  using  each  AP.  The  measurements  for  each  AP  are 
grouped  by  the  hotspot  location  where  they  were  taken,  shown  on  the  x-axis.  The  symbol 
above  each  box  indicates  whether  the  AP  can  be  accessed  for  free  (O)  or  not  ($).  The 
box  for  the  official  AP  at  each  hotspot  is  a  solid  color  and  its  symbol  is  in  a  larger  font. 
The  APs  in  all  graphs  are  sorted  by  their  median  TCP  download  throughput.  Most  of  the 
non-free  APs  at  tullys  2  are  University  of  Washington  APs  in  a  building  across  the  street. 


Time  frame.  Previous  studies  measured  each  AP  at  a  single  point  in  time  [71,  122]. 
Since  we  want  to  know  whether  AP  characteristics  are  predictable,  we  performed  8  to  13 
measurements  at  each  location  (with  the  exception  of  yunnie  bubble  tea,  where  we  only 
performed  6  trials).  These  measurements  were  taken  during  7  week  days  in  October  2008. 
On  each  day,  at  each  location,  we  performed  1-2  measurements  at  different  times  of  the 
day,  so  we  have  at  least  one  measurement  during  each  2  hour  time-of-day  between  9AM 
and  6PM  (or  a  narrower  time  window  if  the  hotspot  opened  later  or  closed  earlier). 
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4.1.2  Results 


Basic  connectivity.  Figure  4.2(a)  shows  the  fraction  of  times  we  were  able  to  obtain 
connectivity  from  each  AP  at  each  location  (i.e.,  association  and  authentication  succeeds, 
we  are  able  to  obtain  a  DHCP  address,  and  able  to  fetch  www .google  .  com;  we  retry 
each  step  up  to  3  times  and  for  up  to  30  seconds  on  failure).  We  only  count  times  when 
the  AP  was  visible  in  a  network  scan.  The  symbol  above  each  point  indicates  whether  the 
AP  can  be  accessed  for  free  (O)  or  not  ($).  The  box  for  the  official  AP  at  each  hotspot  is 
shown  in  a  solid  color  and  its  symbol  is  in  a  larger  font.^ 

As  expected,  most  (10  of  13)  official  hotspot  APs  were  successful  100%  of  the  time. 
However,  some,  such  as  the  ones  at  tullys  1  and  cafesolstice,  failed  several  times.  These 
were  all  DHCP  failures  and  frequent  users  of  cafesolstice  say  that  the  AP  has  always  had 
DHCP  problems.  However,  it  would  be  difficult  to  detect  these  problems  automatically 
because  even  to  attempt  to  access  the  network,  a  user  has  to  obtain  a  WPA  password  from 
the  cashier.  Although  unofficial  APs  visible  at  hotspots  tend  to  fail  with  higher  regularity 
due  to  wireless  loss,  a  few  in  most  (8  of  13)  locations  succeed  whenever  they  were  visible 
in  our  network  scan.  Thus,  even  this  very  basic  connectivity  metric  suggests  that  there  is 
diversity. 

TCP  throughput.  Adequate  throughput  is  important  for  many  applications,  such  as 
streaming  video  or  VoIP.  Figure  4.2(b)  shows  a  box-plot  of  the  TCP  download  throughput 
achieved  through  each  AP  (i.e.,  the  bar  in  the  middle  of  each  box  indicates  the  median; 
the  ends  of  each  box  indicate  the  first  and  third  quantiles;  and  whiskers  indicate  the  mini¬ 
mum  and  maximum).  Note  the  logarithmic  scale.  We  measured  throughput  over  the  final 
five  seconds  of  a  ten-second  transfer  from  a  high  bandwidth  server  under  our  control  to 
estimate  each  AP’s  sustained  throughput  after  TCP  slow  start.  We  do  not  count  the  times 
when  we  failed  to  associate  with  the  AP  or  when  TCP  timed  out  during  establishment  (the 
failure  rate  above  suggests  how  often  this  occurs),  so  we  have  fewer  measurements  for 
some  APs  than  for  others. 

First,  we  note  that  there  is  a  significant  range  in  available  capacities  across  different 
hotspot  locations.  Median  capacities  range  from  less  than  100  Kbps  (yunnie)  to  over  5 
Mbps  (Starbucks  1  and  oasis).  There  is  variability  in  each  AP’s  throughput  measure¬ 
ments,  which  is  attributable  mostly  to  wireless  loss  or  contention  (similar  UDP  throughput 
measurements  had  less  variability),  but  the  variation  at  most  APs  is  much  smaller  than  this 
wide  performance  range.  Therefore,  there  is  diversity  in  AP  capacity,  and  throughput  is 

^cafesolstice  has  2  official  APs  because  it  changed  APs  in  the  middle  of  our  measurement  period. 
However,  both  APs  suffered  from  basic  connectivity  problems. 
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predictable  enough  to  distinguish  them. 

Second,  we  observe  that  there  is  also  a  significant  range  in  capacities  among  APs 
visible  from  a  single  location.  As  expected,  most  (9  of  13)  official  hotspot  APs  have 
the  highest  median  throughputs  at  their  respective  locations.  However,  this  is  not  true 
at  tullys  1,  yunnie,  Starbucks  1,  and  tullys  2,  where  better  APs  were  available  from 
an  apartment  building  next  door,  the  public  seattlewifi  network,  a  store  next  door,  and  a 
nearby  hotel,  respectively.  Indeed,  at  Starbucks  1  and  yunnie,  an  unofficial  AP  always 
gave  significantly  more  throughput  than  the  official  one  when  visible.  Recall  that  these 
comparisons  only  include  measurements  when  we  were  able  to  successfully  pay  for  and 
obtain  Internet  connectivity,  so  a  user  without  historical  information  would  have  to  pay 
before  discovering  this. 

Response  time.  Low  network  latency  is  another  important  attribute  for  interactive  ap¬ 
plications  such  as  web  browsing.  To  estimate  the  latency  a  typical  web  browser  would 
experience,  we  measured  the  response  time  to  one  of  the  most  popular  web  sites.  Fig¬ 
ure  4.2(c)  shows  a  box-plot  of  the  time  to  fetch  http  :  /  /www .  google  .  com.  Fetch 
time  includes  the  time  to  perform  a  DNS  lookup,  which  is  dependent  on  the  DNS  server 
each  AP’s  DHCP  server  assigns  us.^  Since  Google’s  homepage  is  only  6KB,  fetch  time  is 
dominated  by  latency  rather  than  transfer  time.  We  do  not  count  the  times  when  associa¬ 
tion  failed. 

Just  as  we  saw  with  TCP  throughput,  there  is  diversity  in  response  time,  which  ranges 
from  less  than  100  ms  to  several  seconds.  Response  times  of  more  than  1  second  are 
typically  noticeable  by  an  end-user.  As  expected,  most  (10  of  13)  official  APs  have  the 
lowest  median  latency  at  their  respective  hotspot  locations,  but  this  is  not  true  at  tullys 
1,  yunnie,  and  cafeontheave.  Only  the  disparity  between  the  best  and  official  APs  at 
tullys  1  is  large  enough  to  be  noticeable,  but  even  smaller  differences  may  impact  more 
sensitive  applications,  such  as  VoIP.  In  addition,  in  some  cases  the  AP  with  the  lowest 
and  least  variable  response  time  is  not  the  same  as  the  AP  with  the  highest  throughput 
(e.g.,  at  Starbucks  1 ),  so  ranking  is  dependent  on  application  requirements.  Finally,  all 
official  APs,  except  the  one  at  sureshot,  provide  predictable  response  times  (first  and 
third  quantiles  within  a  factor  of  2).  At  least  one  unofficial  AP  at  each  location  is  just  as 
predictable. 

Port  blocking.  To  determine  if  an  AP  blocked  or  redirected  certain  application  ports,  we 
sent  3  probes  to  each  port  on  a  measurement  server  under  our  control.  For  UDP  ports, 
each  probe  consisted  of  44-byte  request  and  response  datagrams,  while  for  TCP  ports, 

^The  CNAME  and  A  DNS  records  for  www .  google  .  com  have  a  TTLs  of  1  week  and  1  day,  respec¬ 
tively,  so  they  are  almost  always  already  cached  at  the  DNS  server. 
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each  probe  tried  to  establish  a  connection  and  download  ~32  bytes  of  data  (in  order  to 
check  for  port  redirection).  We  tested  common  application  ports  including:  FTP,  NTP, 
SSH,  NetBIOS,  SMTP,  IMAP,  SSL,  VoIP  (SIP),  STUN,  common  VPN  ports.  World  of 
Warcraft,  Counterstrike,  Gnutella,  and  Bittorrent.  To  account  for  packet  loss,  we  conclude 
that  a  port  is  blocked  only  if  it  was  never  reachable  in  any  of  our  measurements. 

All  APs  blocked  NetBIOS,  most  likely  because  they  are  configured  to  do  so  by  default. 
Three  APs  blocked  non-DNS  packets  on  port  53  and  only  one  (bookstore’s  official  AP) 
blocked  more  ports:  all  non-privileged  TCP  ports  and  all  UDP  ports  except  DNS  and  NTP. 
Nonetheless,  this  is  useful  information,  as  common  applications  such  as  VPNs,  VoIP,  and 
games  would  not  function. 

Summary.  With  respect  to  diversity,  we  find  that  there  is  significant  diversity  in  AP 
throughput  and  latency.  With  respect  to  rankability,  the  official  AP  is  not  the  best  choice 
at  30%  of  hotspot  locations,  so  ranking  APs  is  not  always  obvious.  Finally,  with  respect 
to  predictability,  there  is  variability  in  performance  over  time,  but  this  variability  is  much 
smaller  than  the  range  of  different  APs’  performance,  so  historical  information  should  be 
predictable  enough  to  compare  APs.  Therefore,  our  results  suggest  that  a  collaborative 
reporting  service  may  improve  AP  selection. 


4.1.3  Discussion 

Why  not  just  use  official  APs?  One  might  ask  whether  historical  information  is  really 
necessary  if  the  official  AP  is  usually  the  best  at  70%  of  locations.  First,  in  Section  4.5.1, 
we  show  that  historical  information  can  get  us  the  best  AP  in  the  remaining  30%.  Second, 
as  hotspot  density  increases,  scenarios  like  these  will  likely  become  more  common.  Third, 
many  users  will  be  willing  to  move  to  find  better  APs  and,  without  historical  information, 
it  is  not  obvious  how  to  determine  where  to  move  to.  Finally,  if  a  user  is  not  in  range  of 
any  APs,  he  needs  historical  information  to  determine  where  to  find  a  good  one. 

Other  selection  factors.  In  practice,  users  will  likely  take  other  factors  into  account 
besides  AP  performance  and  application  support,  such  as  cost  and  venue.  Although  these 
factors  are  important  and  reports  in  Wifi-Reports  can  include  such  information,  they  are 
also  subjective,  so  we  focus  our  evaluation  on  AP  performance.  In  particular,  we  focus 
on  download  capacity  and  latency  since  these  metrics  are  important  for  most  applications. 
Our  focus  demonstrates  Wifi-Reports’  ability  to  help  users  make  more  informed  decisions 
about  which  APs  to  use,  whether  they  take  cost  and  venue  into  account  or  not. 


107 


4.2  Wifi-Reports  Overview 


Wifi-Reports  is  a  recommendation  system  [5].  Users  rate  the  services  they  use  and  sub¬ 
mit  these  ratings  to  a  report  database  where  they  are  summarized.  Other  users  download 
summarized  ratings  to  evaluate  services  that  they  are  considering.  In  Wifi-Reports,  the 
users  are  wireless  clients,  services  are  APs,  and  ratings  are  key- value  pairs  of  measured 
performance  metrics. 


4.2.1  Challenges 

In  contrast  to  previous  recommendation  systems,  Wifi-Reports  faces  two  unique  chal¬ 
lenges: 

Location  privacy.  By  reporting  the  use  of  an  AP,  a  user  implicitly  reveals  a  location 
where  he  has  been  with  an  accuracy  that  is  sufficient  to  identify  sensitive  places  [129]. 
Thus,  users  may  not  be  willing  to  participate  in  Wifi-Reports  if  their  identities  can  be 
linked  to  their  reports.  A  single  user’s  reports  must  not  even  be  linkable  to  each  other, 
otherwise  they  are  vulnerable  to  inference  attacks  [27,  64].  Nevertheless,  we  still  want  to 
limit  the  influence  of  malicious  users  that  submit  fraudulent  reports,  which  is  a  common 
problem  in  recommendation  systems  [162,  176]. 

Location  context.  Clients  will  typically  search  for  summaries  by  location  (e.g.,  “all  APs 
in  Seattle”),  and  the  location  of  a  client  with  respect  to  an  AP  will  affect  its  measured 
performance  due  to  different  wireless  channel  conditions.  Since  we  would  like  clients  to 
generate  reports  automatically,  location  context  must  be  determined  automatically. 


4.2.2  System  Tasks 

The  operation  of  Wifi-Reports  consists  of  three  main  tasks  (Figure  4.3).  We  present  an 
overview  of  these  tasks  here.  The  next  two  sections  describe  how  they  can  be  done  while 
addressing  the  challenges  discussed  above. 

Measure  and  report.  Clients  measure  and  submit  reports  on  APs  that  they  use.  For  ex¬ 
ample,  suppose  a  client  attempts  to  connect  to  the  Internet  using  AP  X.  If  the  connection 
fails  (i.e.,  association,  DHCP,  or  all  TCP  connections  fail),  the  client  generates  the  report 
{ap=X,  SNR=20dB,  date=l  1/14/2008,  connectivity=false}."^  If  the  connection  succeeds, 

refers  to  the  AP’s  BSSID  and  a  hash  of  its  signing  key  described  in  Section  4.3. 
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Figure  4.3:  Wifi-Reports  eomponents  and  typieal  tasks. 

then  the  elient  software  estimates  performanee  metries  based  on  the  user’s  network  traffle 
or  using  aetive  measurements  when  the  eonneetion  is  idle.^  When  measurement  eom- 
pletes,  it  generates  the  report  {ap=X,  SNR=20dB,  date=l  1/14/2008,  eonneotivity=true, 
tcp_bw_down=100kbps,  google _resp_time=5 00ms,  . . .}. 

When  the  elient  has  Internet  eonneetivity  again,  it  eontaets  an  account  authority  to 
obtain  the  right  to  report  on  X,  e.g.,  by  reeeiving  a  eredential.  It  sends  this  report  along 
with  the  eredential  to  a  report  database.  An  aeeount  authority  is  neeessary  to  prevent 
a  single  malieious  elient  from  submitting  an  unbounded  number  of  fraudulent  reports. 
However,  to  preserve  the  loeation  privaey  of  honest  elients,  neither  the  aeeount  authority 
nor  the  report  database  should  learn  that  the  client  used  AP  X.  We  describe  the  novel 
protocol  we  use  to  address  this  problem  in  Section  4.3. 

Download  and  index.  The  database  generates  summary  statistics  for  each  AP  by  sum¬ 
marizing  the  values  for  each  key.  To  be  robust  against  some  fraudulent  values,  we  use 
summary  functions  that  are  not  significantly  skewed  by  a  small  fraction  of  outliers.  For 
example,  median  is  used  for  real-value  attributes  (e.g.,  throughput),  plurality  voting  for 
multinomial  attributes  (e.g.,  port  blocking),  and  average  for  probability  attributes  with 

number  of  techniques  and  tools  exist  to  estimate  bandwidth  [134]  and  response  time  [79].  These 
techniques  are  outside  the  scope  of  this  dissertation,  but  the  measurements  we  used  can  be  implemented  as 
an  anonymous  speed  test. 
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{0, 1}  inputs  (e.g.,  basic  connectivity).  In  addition,  a  summary  indicates  the  number  of 
reports  that  it  summarizes  as  an  estimate  of  its  robustness  (i.e.,  a  user  will  pay  more  heed 
to  a  summary  of  10  different  reports  than  a  summary  of  just  1  report).  A  client  may  choose 
to  ignore  summaries  with  too  few  reports  to  mitigate  the  impact  of  erroneous  reports  by 
early  adopters. 

Before  traveling,  a  user  downloads  and  caches  the  summary  statistics  of  all  APs  in  the 
cities  that  he  expects  to  visit.  In  practice,  client  software  would  update  this  cache  whenever 
it  has  connectivity,  similar  to  the  iPass  [82]  client.  To  find  a  suitable  hotspot,  reports  are 
shown  to  a  user  on  a  map.  In  order  to  facilitate  this  operation,  reports  must  be  search-able 
by  geographic  location.  Unfortunately,  we  cannot  rely  on  GPS  because  many  wireless 
clients  are  not  equipped  with  it  and  it  is  often  does  not  work  indoors.  We  describe  existing 
techniques  that  we  leverage  to  obtain  coarse  geographic  coordinates  in  Section  4.4.1. 

Predict  locally.  Finally,  when  a  user  sits  down  at  a  cafe,  he  typically  wants  to  find  the 
best  AP  that  is  visible.  Although  the  client  will  have  downloaded  summaries  for  these  APs 
earlier,  the  expected  performance  of  each  AP  depends  on  the  wireless  channel  conditions 
between  the  client  and  the  AP.  For  example,  conditions  will  vary  based  on  the  observed 
signal-to-noise  ratio  (SNR).  Therefore,  the  client  must  apply  a  filter  to  the  summaries  to 
obtain  an  accurate  prediction  for  the  current  conditions.  We  describe  how  a  client  can 
perform  this  filtering  in  Section  4.4.2. 


4.3  Location  Privacy 

This  section  describes  a  novel  report  submission  protocol  that  ensures  location  privacy 
and  limited  influence,  properties  that  we  define  below.  Define  U  to  be  the  set  of  all  users 
that  participate  in  Wifi-Reports,  S  to  be  the  current  set  of  all  APs,  u  =  submitter(i?)  to  be 
the  user  that  submitted  report  R,  and  s  =  target(i?)  be  the  AP  that  R  reports  on.  Suppose 
C  <ZU  h  the  largest  set  of  colluding  malicious  users  that  try  to  violate  any  user’s  location 
privacy  or  to  influence  an  AP’s  summary. 

Location  privacy.  To  preserve  location  privacy,  we  must  satisfy  three  conditions.  (1)  No 
one,  not  even  the  account  authority  or  report  database,  should  be  able  to  link  any  report  to 
its  submitter;  i.e.,  no  one  should  be  able  to  guess  submitter(i(j)  with  probability  greater 
than  ,  for  all  reports  i?*.  (2)  No  one  should  be  able  link  any  two  reports  together 
unless  they  were  submitted  by  the  same  user  for  the  same  AP;  i.e.,  no  one  should  be  able 
to  guess  whether  submitter(i?j)  =  submitter(i?j)  with  probability  greater  than  for 
all  Ri,  Rj  where  submitter(i(i)  submitter(i?j)  or  target (i?*)  target(/(j).  (3)  A  user 
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should  not  have  to  reveal  the  target  of  a  report  in  order  to  obtain  the  right  to  submit  the 
report;  i.e.,  after  obtaining  the  right  to  submit  Rk+i,  the  account  authority  should  not  be 
able  to  guess  target(i?fc+i)  with  probability  greater  than  In  practice,  achieving  this 
third  condition  may  be  too  expensive,  so  we  later  relax  it  by  restricting  S  to  all  APs  in  a 
city  rather  than  all  APs. 

Limited  influence.  To  limit  the  influence  of  dishonest  users,  exactly  one  report  from  each 
user  who  has  submitted  a  report  on  AP  s  should  be  used  to  compute  the  summary  statistics 
for  s.  To  ensure  that  this  condition  is  satisfied,  any  two  reports  submitted  by  the  same  user 
for  the  same  AP  must  be  linked;  i.e.,  for  all  i?*,  Rj  where  submitter(i?j)  =  submitter(i?j) 
and  target(i?j)  =  target(i?j),  anyone  should  be  able  to  verify  that  submitter(i?j)  = 
submitter(i?j).  When  computing  each  summary,  the  database  first  summarizes  each  in¬ 
dividual  user’s  reports  and  then  computes  a  summary  over  these  summaries.  This  ensures 
that  malicious  users  have  at  most  \C\  votes  on  the  final  summary. 

We  may  also  want  to  limit  the  rate  at  which  these  users  can  submit  reports  on  any  AP. 
For  example,  we  may  want  to  prevent  a  malicious  user  from  reporting  on  a  large  number  of 
APs  that  he  has  never  actually  visited.  We  discuss  how  to  achieve  this  additional  property 
at  the  end  of  Section  4.3.3. 


4.3.1  Threat  Model 

Users’  location  privacy  should  be  protected  from  malicious  users,  the  account  authority, 
and  report  databases.  To  meet  this  goal,  we  don’t  assume  any  restrictions  on  the  behavior 
of  malicious  users,  but  we  make  a  few  practical  assumptions  about  the  account  authority 
and  report  databases. 

Account  authority.  A  challenge  for  recommendation  systems  is  how  to  prevent  malicious 
users  from  out- voting  honest  users,  e.g.,  by  using  botnets  or  Sybil  attacks  to  obtain  many 
fake  identities.  Wifi-Reports,  as  with  most  existing  recommendation  systems,  assumes  that 
a  central  account  authority  can  limit  these  large-scale  attacks.  For  example,  the  authority 
can  require  a  credential  that  is  hard  to  forge,  such  as  a  token  credit  card  payment  or  the 
reception  of  an  SMS  message  on  a  real  cell  phone.  These  defenses  are  not  perfect,  but 
are  enough  of  a  deterrent  that  existing  recommender  systems  work  well  in  practice.  These 
heuristics  may  also  be  supplemented  by  Sybil  detection  schemes  (e.g.,  [175]).  Thus,  we 
assume  that  these  mechanisms  are  sufficient  to  bound  the  number  of  malicious  users  to 
a  small  fraction  of  the  total  number  of  users.  Section  4.5.3  shows  that  our  system  can 
limit  the  influence  of  this  small  number  of  malicious  users.  We  assume  that  the  account 
authority  is  honest  but  curious;  that  is,  it  may  try  to  reveal  information  about  users,  but 
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it  does  not  violate  our  protocol.  We  discuss  how  selfish  violations  can  be  detected  in  the 
next  two  sections.  Since  the  account  authority  is  a  high  profile  entity,  we  believe  that  the 
legal  implications  of  violations  are  sufficient  deterrents  to  prevent  them. 

Report  databases.  Users  have  to  trust  the  report  database  to  summarize  reports  correctly. 
To  distribute  this  trust,  we  assume  that  there  are  multiple  databases  and  that  most  are 
honest  (e.g.,  do  not  delete  reports  prematurely).  Honest  users  submit  reports  to  all  the 
databases  and  download  summary  statistics  from  all  databases,  using  the  report  on  each 
AP  that  the  majority  of  databases  agree  upon.  We  note  that  the  existence  of  a  single 
honest  database  can  be  used  to  audit  all  databases,  because  any  valid  report  that  exists 
should  exist  on  all  the  databases,  and  reports  are  independently  verifiable  (see  the  protocol 
below).  Independent  verifiability  also  means  that  each  database  can  periodically  check  the 
others  to  discover  and  obtain  reports  that  it  is  missing.  We  assume  that  users  learn  about 
the  list  of  report  databases  in  an  out-of-band  manner;  e.g.,  it  may  be  distributed  with  the 
software. 

A  report  database  can  link  reports  if  they  are  submitted  from  the  same  IP  address. 
Therefore,  we  assume  that  users  submit  reports  through  a  mix  network  such  as  Tor  [49] 
and  that  the  mix  achieves  its  goal,  i.e.,  no  one  can  infer  the  source  IP  address  of  the  sender’s 
messages. 

4.3.2  Straw  Man  Protocols 

Anonymize  reports.  One  approach  might  be  to  have  users  simply  submit  reports  to  the 
databases  via  a  mix  network.  This  means  that  all  reports  are  unlinkable,  thus  providing 
location  privacy.  However,  this  protocol  does  not  provide  limited  influence  because  a 
database  can  not  distinguish  when  one  user  submits  many  reports  on  an  AP  versus  when 
many  users  submit  one  report  each  on  the  AP. 

Authenticate  reports.  For  this  reason,  nearly  all  existing  recommender  systems  today 
rely  on  a  trusted  central  authority  that  limits  each  real  user  to  a  single  account.  We  can 
limit  influence  with  an  authority  A  as  follows:  When  a  user  Ui  wants  to  submit  a  report  R 
on  AP  Sj,  it  authenticates  itself  to  A  (e.g.,  with  a  username/password)  and  then  sends  R 
to  A.  A  checks  if  Ui  has  previously  submitted  any  reports  on  sj  and,  if  so,  deletes  them 
from  the  report  databases  before  adding  the  new  one.  A  explicitly  remembers  the  user  that 
submitted  each  report.  If  A  is  the  only  one  allowed  to  add  and  remove  reports  from  the 
report  databases,  this  protocol  provides  limited  influence  because  each  user  is  limited  to 
one  report.  However,  it  fails  to  provide  location  privacy  with  respect  to  A.  Indeed,  A  must 
remember  which  reports  each  user  submitted  to  prevent  multiples. 
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4.3.3  Blind  Signature  Report  Protocol 


To  achieve  both  location  privacy  and  limited  influence,  Wifi-Reports  uses  a  two  phase 
protocol.  We  sketch  this  protocol  here:  First,  when  user  Ui  joins  Wifi-Reports,  the  account 
authority  A  provides  him  with  a  distinct  signed  “token”  Kij  for  each  AP  Sj  e  S.  By  using 
a  blind  signature  [21],  no  one,  including  A,  can  link  K^j  to  the  user  or  to  any  other  Kij/. 
This  ensures  location  privacy.  However,  anyone  can  verify  that  A  signed  K^j  and  that  it 
can  only  be  used  for  Sj.  GenToken  describes  this  step  in  detail  below.  Second,  to  submit 
a  report  R  on  AP  Sj,  Ui  uses  the  token  Kij  to  sign  R,  which  proves  that  it  is  a  valid  report 
for  Sj.  Ui  publishes  R  to  each  report  database  anonymously  via  the  mix  network.  Since 
Ui  only  has  one  token  for  Sj,  all  valid  reports  that  Ui  submits  on  Sj  will  be  linked  by  K^. 
This  ensures  limited  influence.  SubmitReport  describes  this  step  in  detail  below. 

Preliminaries.  The  RSA  blind  signature  scheme  [21]  is  a  well  known  cryptographic 
primitive  that  we  use  in  our  protocol.  Let  blind (iF,  m,  r)  and  unblind(iF,  m,  r)  be  the 
RSA  blinding  and  unblinding  functions  using  RSA  public  key  K,  message  m,  and  ran¬ 
dom  blinding  factor  r  (we  use  1024-bit  keys  and  values).  Let  sign(A'“\  m)  be  the  RSA 
signature  function  using  RSA  private  key  K~^,  and  let  verify(iF,  m,  x)  be  the  RSA  verifi¬ 
cation  function,  which  accepts  the  signature  x  if  and  only  if  a;  =  sign(A'“^,  m).  Let  if  (m) 
be  a  public  pseudorandom  hash  function  (we  use  SHA-512).  We  leverage  the  following 
equivalence: 

sign(A'“\m)  =  unblind(A',  sign(iF“\  blind(A',  m,  r)),  r) 

That  is,  blinding  a  message,  signing  it,  and  then  unblinding  it  results  in  the  signature  of 
the  original  message. 

Blind  signatures  have  two  important  properties.  (1)  Blindness:  without  knowledge  of  r, 
ffi  =  blind(iF,  m,  r)  does  not  reveal  any  information  about  m.  (2)  Unforgeability:  suppose 
we  are  given  valid  signatures  {xi,X2, . . . ,  Xk)  for  each  of  (mi,  m2, . . . ,  nik),  respectively, 
where  m*  =  H{fhi).  Without  the  secret  key  K~^,  it  is  infeasible  to  forge  a  new  signature 
Xk+i  =  sign(A'“^,  H{mk+i))  for  any  nik+i  7^  bhi  for  all  i,  under  the  assumption  that  the 
known-target  or  chosen-target  RSA-inversion  problems  are  hard  [21].  However,  anyone 
can  check  whether  verify(iF,  iF(mj),  a;*)  accepts. 

Protocol  description.  Our  protocol  has  two  phases:  GenToken  and  SubmitReport, 
described  below.  For  now,  assume  that  the  set  of  APs  S  is  fixed  and  public  knowledge. 
We  describe  later  how  APs  enter  and  leave  this  set. 

GENTOKEN(Mj,  Sj).  The  GenToken  phase  is  used  by  user  Ui  to  obtain  a  token  to 
report  on  AP  Sj  and  Ui  only  performs  it  once  per  Sj  in  ufs  lifetime.  Sj  identifies  an 
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AP  by  BSSID  as  well  as  a  hash  of  A’s  signing  key  for  that  AP  (see  below),  i.e.,  sj  = 
{bssidj,  H{bssidj\Mj)}.  We  assume  that  Ui  and  A  mutually  authenticate  before  engaging 
in  the  following  protocol  (e.g.,  with  SSL  and  a  secret  passphrase). 

A  :  {M,  M-^j,  {Mj,  M-^}  Vsj  G 

msigj  ^  S\Qr\{M~^ ,  H{bssidj\Mj))  ^sj  G  S 
u,  :  M,  Mj,  msig„  r  A  {0, 


m:  b^  blind(M^-,  H{Kij),r)  (4.1) 

Ui  ^  A  :  "sig-request ",  Sj,  6  (4.2) 

A:  sig'j  ^  Sign  (M-\b)  (4.3) 

A  ^  Ui  :  "sig-reply",  (4.4) 

Ui  :  sigij  ^  unb\\n6{Mj,  sig[j,r)  (4.5) 


The  lines  before  step  4.1  show  items  that  are  obtained  before  the  protocol  begins.  A 
has  a  single  master  RSA  key  pair  M,  M~^  and  has  generated  a  different  signing  RSA  key 
pair  Mj,  M~^  for  each  Sj.  H{bssidj\Mj)  is  signed  by  the  authority’s  master  key  so  that 
others  can  identify  Mj  as  a  signing  key  for  bssidj.  M,  Mj,  and  msigj  are  publicly  known 
(e.g.,  given  to  users  and  databases  by  A  when  they  join).  Ui  generates  a  new  reporting 
key  pair  Kij,  K~^  and  a  1024-bit  random  value  r.  After  step  4.2,  A  checks  whether  it  has 
already  sent  a  sig-reply  message  to  Ui  for  Sj.  If  so,  it  aborts,  otherwise  it  continues. 
After  step  4.5,  Ui  checks  that  verify  (Mj ,  II  (K^) ,  sigij)  accepts.  At  completion,  Ui  saves 
Kij,  K~j^,  and  sigij  for  future  use. 

This  exchange  can  be  described  as  follows:  A  authorizes  the  reporting  key  Kij  for  use 
on  reports  for  Sj  by  blindly  signing  it  with  Sj’s  signing  key  By  blindness,  A  does  not 
learn  Kij,  only  that  the  client  now  has  a  key  for  Sj.  Thus,  no  one  can  link  Kij  to  user  Ui  or 
to  any  Ku,  I  ^  j.  [K^j,  sigij}  is  the  token  that  Ui  attaches  to  reports  on  Sj.  When  a  report 
is  signed  with  K~-^,  this  token  proves  that  the  report  is  signed  with  an  authorized  signing 
key.  Since  A  only  allows  each  user  to  perform  GenToken  once  per  AP,  each  user  can 
only  obtain  one  authorized  reporting  key  for  Sj.  By  unforgeability,  even  if  multiple  users 
collude,  they  cannot  forge  a  new  authorized  reporting  key. 

SUBMlTREPORT(Mj,  Sj,  R).  This  phase  is  used  by  user  Ui  to  submit  a  report  R  on  AP  Sj 


after  a  token  for  Sj  is  obtained.  Let 

{Di, . . . ,  Dm}  be  the  m  independent  databases.  R  is 

submitted  to  each  as  follows. 

Dk  '■ 

M,  Mj  ysj  G  S 

Ui  . 

rsig  ^  siQn{K-.\H{R)) 

(4.6) 

Ui  ^  . 

"report " ,Sj,  Kij,  sigij,  R,  rsig 

(4.7) 
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The  message  in  step  4.7  is  sent  through  a  mix  network  so  it  does  not  explieitly  reveal  its 
sender.  After  step  4.7,  Dk  eheeks  that  verify(Mj  ,  77(7^^),  sigij)  and  verify (77*^  ,  H {R),rsig) 
both  aeeept.  If  any  of  these  eheeks  fail,  the  report  is  invalid  and  is  disearded.  In  other 
words,  Ui  anonymously  publishes  a  report  R  signed  using  K~j^.  By  ineluding  {Kij,  sigij}, 
anyone  ean  verify  that  the  signature  is  generated  using  a  key  signed  by  M~^,  i.e.,  a  key 
that  A  authorized  to  report  on  sj  during  the  GenToken  phase. 

Anonymizing  GenToken.  This  protoeol  aehieves  limited  influenee  and  prevents  eaeh 
report  from  being  linked  to  any  user  or  any  other  report.  However,  if  a  user  engages  in 
GenToken (tij,  sj)  only  when  it  reports  on  sj,  then  it  reveals  to  A  that  it  is  reporting  on 
Sj.  In  order  to  satisfy  the  third  eondition  of  our  loeation  privaey  requirement,  that  A  eannot 
guess  the  AP  with  probability  greater  than  Ui  would  have  to  perform  GenToken  on 
all  s  G  5  before  submitting  any  reports  so  that  A  eannot  infer  whieh  tokens  were  used. 

When  performing  GenToken  on  all  APs  is  too  expensive,  we  relax  this  eondition 
as  follows.  We  allow  A  to  infer  that  the  AP  is  in  a  smaller  set  S  C  S.  Determining  an 
appropriate  set  ^  is  a  trade-off  between  more  loeation  privaey  and  less  time  spent  perform¬ 
ing  GenToken  operations.  We  have  users  explieitly  ehoose  a  region  granularity  they  are 
willing  to  expose  (e.g.,  a  eity).  When  reporting  on  an  AP,  they  perform  GenToken  on 
all  APs  in  this  region.  We  believe  this  small  eompromise  in  loeation  privaey  is  aeeeptable 
sinee  users  already  volunteer  eoarse-grained  loeation  information  to  online  serviees  (e.g., 
to  get  loealized  news)  and  IP  addresses  themselves  reveal  as  mueh.  In  Seetion  4.5,  we 
show  that  using  the  granularity  of  a  eity  is  praotieal.^ 

Handling  AP  churn.  To  support  ehanges  in  the  set  of  APs  S,  A  maintains  S'  as  a  dynamie 
list  of  APs.  Any  user  ean  request  that  A  add  an  AP  identified  by  BSSID  and  loeated 
via  beaeon  fingerprint  (see  Seetion  4.4.1).  A  generates  a  new  signing  key  pair  and  its 
signature  {Mj,  msigj  ^  S\Qn{M~^ ,  H {bssidj\Mj)),  and  the  new  AP  is  identified 

by  Sj  =  {bssidj,  H{bssidj\Mj)}.  Mj  and  msigj  are  given  to  the  user  and  he  submits  them 
along  with  the  first  report  on  Sj  to  each  report  database.  AP  addition  is  not  anonymous, 
as  the  user  must  reveal  the  AP  to  A,  so  Wifi-Reports  will  initially  depend  on  existing 
hotspot  and  war  driving  databases  and  altruistic  users  to  populate  S.  However,  over  time 
we  believe  that  owners  of  well-performing  APs  will  be  incentivized  to  add  themselves 
because  otherwise  they  will  not  receive  any  reports.  An  AP  is  removed  from  S  if  it  is 
not  reported  on  in  3  months  (the  report  TTL,  see  below)  and  A  sends  a  revocation  of 
their  signing  keys  to  each  database.  Users  can  thus  obtain  new  signing  public  keys  and 

®An  alternative  solution  is  to  perform  GenToken  on  a  random  subset  of  n  APs  in  addition  to  the  target 
AP.  However,  since  a  user  will  likely  submit  reports  on  multiple  correlated  APs  (e.g.,  APs  in  the  same  city), 

A  can  exploit  correlations  to  infer  the  APs  actually  reported  on. 
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revocations  from  each  database. 

We  take  three  steps  to  limit  the  impact  of  nonexistent  or  mislocated  APs  that  malicious 
users  may  add.  (1)  When  searching  for  APs  on  a  map,  the  client  report  cache  filters  out 
APs  that  only  have  a  small  number  of  recent  reports;  these  APs  require  more  “locals”  to 
report  on  them  before  distant  users  can  find  them.  (2)  After  a  sufficient  number  of  reports 
are  submitted,  reported  locations  are  only  considered  if  a  sufficient  number  are  near  each 
other,  and  the  centroid  of  those  locations  is  used.  (3)  A  rate  limits  the  number  of  additions 
each  user  can  make. 

Handling  long-term  changes.  AP  performance  can  change  over  time  due  to  back-haul 
and  AP  upgrades.  However,  these  changes  typically  occur  at  timescales  of  months  or  more. 
Thus,  reports  have  a  time-to-live  (TTL)  of  3  months.  Databases  discard  them  afterward. 
Determining  the  most  appropriate  TTL  is  a  trade-off  between  report  density  and  staleness 
and  is  a  subject  of  future  work. 

Handling  multiple  reports.  Our  protocol  allows  Ui  to  submit  multiple  reports  on  sj, 
which  can  be  useful  if  they  are  from  different  vantage  points  or  reflect  changes  over  time; 
however,  each  report  on  sj  will  be  linked  by  the  key  Kij.  To  ensure  limited  influence,  a 
database  needs  to  summarize  each  user’s  reports  on  sj  before  computing  a  summary  over 
these  individual  summaries.  For  simplicity,  it  computes  an  individual  user’s  summary  as 
just  the  most  recent  report  from  that  user  that  was  taken  in  the  same  channel  conditions 
(see  Section  4.4.2).^  As  a  consequence,  there  is  no  need  for  an  honest  user  to  submit  a  new 
report  on  sj  unless  the  last  one  it  submitted  expired  or  if  s/s  performance  substantially 
changed.  This  approach  also  allows  a  client  to  mitigate  timing  side-channels  (discussed 
below)  by  randomly  dating  his  reports  between  now  and  the  date  in  his  last  report  on  sj 
without  changing  s/s  summary  statistics.^ 

Rate  limiting  reports.  As  mentioned  earlier,  it  may  also  be  desirable  to  limit  the  rate 
at  which  an  individual  user  can  submit  reports,  say,  to  at  most  t  reports  per  week.  This 
can  be  accomplished  with  a  straight  forward  extension  of  the  SubmitReport  stage  of 
the  protocol:  A  keeps  count  of  the  number  of  reports  that  each  user  submits  this  week. 
Before  submission  of  report  =  {sj,  Kij,  sigij,  R,rsig}  (step  4.7),  user  Ui  sends  h  = 

more  sophisticated  summarization  algorithm  might  use  the  mean  or  median  values  of  all  a  user’s 
reports,  weighted  by  report  age.  We  leave  the  comparison  of  summary  functions  to  future  work  as  we  do  not 
yet  know  how  many  reports  real  users  would  submit  on  each  AP. 

*If  the  owner  of  Kij  is  ever  exposed,  then  an  adversary  learns  some  approximate  times  when  Ui  used  sj. 
If  Ui  knows  this,  he  can  prevent  any  further  disclosures  by  proving  to  A  that  he  revoked  Kij  and  obtaining  a 
new  token  for  sj  using  GenToken;  i.e.,  Ui  can  send  { "revoke",  Kij,  ksig}  to  A  and  the  databases, 
where  ksig  ^  sign(Ar(^^,  7f(" revoke  " \ui\Kij)),  which  proves  that  Ui  has  ’s  secret  key  and  that  Kij 
(and  all  reports  signed  with  it)  is  revoked. 
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blind(M,  H (report) ,  r)  to  A.  If  Ui  has  not  already  exceeded  t  reports  this  week,  A  sends 
Isig'  =  sign(M“^,/i)  back  to  Wj,  and  unblinds  I  si  g'  to  obtain  I  si  g  =  S\Qn{M~^ ,  H  (report)). 
Isig  is  included  in  the  report  submitted  to  the  report  databases  and  is  verified  to  be  correct 
by  recipients.  The  user  would  submit  the  report  to  the  database  at  a  random  time  after 
obtaining  Isig,  so  A  would  only  be  able  to  infer  that  it  was  requested  by  some  user  in  the 
recent  past,  but  not  which  one. 

10-20  would  be  reasonable  values  for  t;  analysis  of  Wi-Fi  probes  shows  most  clients 
have  not  used  more  than  20  APs  recently  [63].  This  approach  only  adds  4  ms  of  computa¬ 
tional  overhead  on  A  per  report  submitted  (see  Section  4.5.2). 

4.3.4  Discussion 

BSSID  spoofing.  One  obvious  concern  is  that  some  APs  can  change  their  BSSID  identi¬ 
ties.  For  example,  a  poorly  performing  AP  might  spoof  the  BSSID  of  a  good  AP  to  hijack 
its  reputation.  Ideally,  each  AP  would  have  a  public  key  pair  to  sign  its  beacons.  APs  could 
then  be  identified  by  the  public  key  instead  of  BSSID  to  prevent  spoofing.  In  802.1 1,  APs 
can  offer  this  signature  and  its  public  key  as  part  of  a  vendor-specific  information  element 
or  as  part  of  802.  IX  authentication.  Without  public  key  identities,  we  can  still  mitigate 
spoofing  with  two  techniques:  First,  if  an  AP  masquerades  as  another  AP  that  is  geo¬ 
graphically  far  away,  then  reports  on  each  will  be  summarized  separately  as  distinct  APs 
and  users  will  treat  them  as  such.  Second,  if  an  AP  attempts  to  spoof  one  that  is  nearby,  the 
distribution  of  beacon  SNRs  that  users  receive  will  likely  have  two  distinct  modes.  This  at 
least  enables  users  (and  the  original  AP)  to  detect  spoofing,  though  resolution  requires  ac¬ 
tion  in  the  “real  world”  since  the  802.11  protocol  cannot  distinguish  the  two  APs.  Finally, 
laws  against  device  fraud  (e.g.,  [57])  may  be  a  sufficient  deterrent  in  practice. 

Eclipse  attacks.  If  A  only  reveals  sj  to  a  single  user  Ui,  A  will  know  that  any  report  for 
Sj  is  submitted  by  m*.  Therefore,  u/s  view  of  the  set  of  APs  S  is  obtained  from  the  report 
databases  rather  than  from  A.  Recall  that  the  identity  of  sj  =  {bssidj,  II(bssidjjMj)}  is 
added  to  each  database  when  sj  is  added  to  S.  Because  a  malicious  database  colluding 
with  A  could  tie  bssid  to  a  different  signing  key  Mj/,  clients  only  consider  AP  identities 
that  the  majority  of  report  databases  agree  upon. 

Side-channel  attacks.  Side-channels  exposed  in  reports  may  potentially  link  reports  if 
the  adversary  has  additional  information.  For  example,  if  only  one  user  visits  an  AP  on  a 
given  day,  the  AP  can  infer  that  any  report  with  a  timestamp  on  that  day  is  from  that  user. 

If  a  user  submits  many  reports  on  APs  at  a  time  when  most  users  rarely  submit  reports, 
the  receiving  database  may  infer  from  the  submissions’  timing  that  they  are  linked.  Since 
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we  add  a  small  amount  of  noise  to  timestamps  and  submission  times,  we  believe  we  can 
defeat  most  of  these  attacks  in  practice  without  significantly  degrading  accuracy. 


4.4  Location  Context 

This  section  describes  how  Wifi-Reports  obtains  geographic  coordinates  for  reports  and 
how  summary  statistics  are  filtered  by  wireless  channel  condition. 


4.4.1  Geographic  Positioning 

To  obtain  coarse  geographic  coordinates  for  APs,  we  leverage  previous  work  on  beacon 
“fingerprints.”  The  set  of  Wi-Fi  beacons  and  their  signal  strengths  observed  from  a  location 
can  be  used  to  obtain  geographic  coordinates  with  a  median  accuracy  of  25  meters  when 
paired  with  a  sufficiently  dense  war  driving  database  [101].  Existing  war  driving  databases 
are  sufficient  to  facilitate  this  task  (e.g.,  Skyhook  [145]  is  used  to  geolocate  iPods).  Thus, 
Wifi-Reports  clients  include  estimated  coordinates  in  reports.  To  generate  the  location 
estimate  in  summary  statistics  for  each  AP,  the  database  uses  the  centroid  of  all  reported 
positions  that  are  close  together  (e.g.,  within  two  city  blocks).  Although  these  positions 
may  be  off  by  tens  of  meters,  we  believe  that  they  are  sufficiently  accurate  for  locating 
areas  of  connectivity  on  a  map.  Network  names  can  be  correlated  with  business  names 
to  improve  accuracy  (e.g.,  from  Google  Maps),  but  doing  this  is  outside  the  scope  of  this 
dissertation.  We  note  that  coordinates  are  only  needed  to  allow  clients  to  search  for  AP 
summary  statistics  by  location. 


4.4.2  Distinguishing  Channel  Conditions 

Wireless  performance  differs  based  on  channel  conditions,  which  vary  based  on  fine¬ 
grained  location  and  environmental  conditions.  The  loss  rate  of  a  wireless  channel  is 
roughly  inversely  proportional  to  the  SNR,  barring  interference  from  other  stations  or 
multi-path  interference  [86].  The  most  obvious  approach  is  to  use  summary  statistics 
that  only  consider  the  k  reports  with  SNR  values  closest  to  the  currently  observed  SNR. 
However,  this  approach  has  two  problems.  First,  it  requires  users  to  download  a  differ¬ 
ent  summary  for  each  possible  SNR  value  for  each  AP.  Second,  it  may  not  be  possible  to 
choose  an  appropriate  k:  if  /c  is  too  large,  summaries  will  consider  many  irrelevant  reports; 
too  small  and  summaries  become  vulnerable  to  outliers  and  fraud. 
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Fortunately,  the  continuum  of  SNR  values  can  be  partitioned  into  three  ranges  with 
respect  to  wireless  loss:  a  range  where  clients  experience  near  100%  loss,  a  range  where 
clients  experience  intermediate  loss,  and  a  range  where  clients  experience  near  0%  loss  [86] . 
Therefore,  Wifi-Reports  categorizes  reports  based  on  these  three  channel  conditions.  In 
other  words,  clients  measure  the  median  SNR  of  beacons  sent  by  their  AR  Reports  are 
annotated  with  this  median  SNR.  When  a  client  makes  a  local  prediction  about  an  AP,  it 
considers  only  previous  reports  taken  in  the  same  SNR  range.  In  practice,  the  database 
creates  one  summary  for  each  of  the  three  ranges  for  each  AP,  so  the  client  does  not  need 
to  download  all  the  reports  for  an  AP 

Since  measured  SNR  depends  on  the  AP’s  transmit  power,  these  three  SNR  ranges  may 
be  different  for  each  AP  We  estimate  these  ranges  as  follows:  Typical  scenarios  exhibit  an 
intermediate  loss  range  of  10  dB  [86],  so  we  exhaustively  search  for  the  “best”  10  dB  range 
that  satisfies  the  expected  loss  rates.  Specifically,  let  be  the  mean  measured  throughput 
of  reports  taken  with  SNR  larger  than  the  10  dB  range,  t=  be  the  average  throughput  of 
reports  with  SNR  in  the  10  dB  range,  and  t<  be  the  average  throughput  of  reports  with  SNR 
smaller  than  the  10  dB  range.  We  find  the  10  dB  range  that  maximizes  (f> — f=)  +  {t=  — 1<), 
or  the  differences  between  the  mean  throughput  in  the  three  ranges.^  We  assume  that 
reports  of  connectivity  failures  experienced  100%  loss  (i.e.,  have  throughput  of  0).  Finally, 
if  f<  <  0.75  ■  t=,  we  likely  only  have  measurements  in  one  of  the  100%  or  0%  loss  ranges, 
so  we  put  all  measurements  in  a  single  range. 

Figure  4.4  shows  the  estimated  ranges  for  several  APs  in  our  measurement  study  that 
were  visible  from  multiple  locations.  We  note  that  we  do  not  need  the  distinguishing 
algorithm  to  work  perfectly  to  obtain  accurate  predictions.  There  is  already  measurement 
noise  within  a  single  loss  region  due  to  TCP’s  sensitivity  to  loss.  Thus,  very  inaccurate 
summaries  typically  only  arise  due  to  mixing  reports  in  the  0%  loss  region  with  the  100% 
loss  region  so  it  usually  suffices  to  estimate  these  regions  within  10  dB.  Clients  could  also 
directly  measure  wireless  loss,  either  by  observing  other  users’  traffic  [160]  or  by  actively 
probing  each  AP 


4.4.3  Discussion 

Client  calibration.  We  use  SNR  to  differentiate  wireless  channel  conditions,  but  the 
reported  SNR  may  have  a  bias  due  to  manufacturing  defects  in  Wi-Fi  NICs.  Therefore, 

®When  we  have  more  than  a  few  samples  (i.e.,  >  5),  we  use  the  median  rather  than  the  mean  because  it 
is  more  robust  to  outliers.  Since  the  distribution  of  noise  is  likely  Gaussian,  the  median  is  likely  to  be  close 
to  the  mean. 
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Figure  4.4:  Estimated  100%,  intermediate,  and  0%  loss  regions  for  three  APs  in  our  mea¬ 
surement  study. 

different  elients  need  to  ealibrate  their  reported  SNR  values.  Previous  work  suggests  that 
most  of  this  error  may  be  eliminated  using  a  loeally  eomputed  offset  [86].  Reported  SNR 
values  for  most  eards  after  self-ealibration  may  vary  by  4  dB,  a  bias  unlikely  to  affeet  our 
algorithm’s  aeeuraey  signifieantly  beeause  the  transitions  between  eaeh  SNR  range  are 
not  sharply  defined.  To  further  improve  aeeuraey,  we  ean  leverage  existing  self-ealibration 
teehniques  that  determine  the  biases  of  sensors  (e.g.,  [14]).  Implementing  a  distributed 
ealibration  algorithm  is  the  subjeet  of  future  work. 

Other  environmental  factors.  To  improve  predietion  aeeuraey  further,  existing  teeh¬ 
niques  ean  be  used  to  measure  and  take  into  aeeount  other  environmental  faetors  that 
eause  variation,  sueh  as  multi-path  interferenee  and  wireless  eontention  [151,  160].  How¬ 
ever,  we  found  that  eontention  is  rare  in  our  measurement  study,  so  predietion  aeeuraey  is 
good  even  diseounting  these  faetors  (see  Seetion  4.5). 

User  and  AP  mobility.  To  localize  reports,  we  currently  assume  that  users  and  APs 
are  stationary.  If  users  are  mobile,  performance  may  change  over  time;  we  can  detect 
user  mobility  by  changing  SNR  values.  Our  current  set  of  active  measurements  are  short- 
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lived  and  can  thus  be  associated  with  the  SNR  values  observed  when  they  are  measured. 
Geolocating  these  mobile  APs  (e.g.,  those  on  a  train)  in  a  manner  that  makes  sense  is  an 
area  of  future  work. 


4.5  Evaluation 

We  evaluate  the  utility  and  practicality  of  Wifi-Reports  using  our  measurement  study  (see 
Section  4.1)  and  our  implementation  of  the  reporting  protocol  (see  Section  4.3).  This 
section  presents  our  evaluation  of  three  primary  questions: 

•  Some  APs’  performance  changes  over  time  and  at  different  locations.  Are  reports 
accurate  enough  to  improve  AP  selection? 

•  Our  reporting  protocol  provides  location  privacy  at  the  cost  of  token  generation  over¬ 
head.  Can  Wifi-Reports  provide  users  with  a  reasonable  amount  of  location  privacy 
with  practical  token  generation  overheads? 

•  A  determined  attacker  may  be  able  to  trick  the  account  authority  into  giving  it  a  few 
accounts  or  collude  with  his  friends  to  submit  multiple  fraudulent  reports  on  an  AP. 
How  tolerant  are  summaries  to  such  attacks? 

4.5.1  AP  Selection  Performance 

Setup.  We  use  our  measurement  study  to  simulate  two  scenarios:  First,  we  evaluate 
the  scenario  where  a  user  chooses  which  hotspot  to  go  to  physically  based  upon  the 
predicted  performance  of  all  hotspots  nearby.  In  this  scenario,  a  user  is  primarily  in¬ 
terested  in  prediction  accuracy;  i.e.,  we  want  predict(s) /actual (s)  to  be  close  to  1  for 
each  AP  s,  where  predict(s)  is  the  predicted  performance  (e.g.,  throughput)  of  s  and 
actual (s)  is  the  actual  performance  of  s  when  it  is  used.  Second,  we  evaluate  the  sce¬ 
nario  where  the  physical  location  is  fixed  (e.g.,  the  user  is  already  sitting  down  at  a 
cafe)  but  the  user  wants  to  choose  the  AP  that  maximizes  performance.  This  situation 
is  comparable  to  the  traditional  AP  selection  problem  [122,  151,  160];  i.e.,  given  the 
set  of  visible  APs  V  =  {si,  S2, . . . ,  Sn},  we  want  a  selection  algorithm  select(-)  that 
maximizes  actual(select(l/)),  where  s  =  select(I^)  is  the  AP  we  choose.  In  this  sce¬ 
nario,  a  user  is  primarily  interested  in  relative  ranking  accuracy;  e.g.,  for  throughput, 
we  would  like  to  maximize  actual (select(I/) )/ max^gy  (actual (s)).  In  Wifi-Reports 
select(y)  =  argmax^gy  (predict(s)). 
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Figure  4.5:  CDF  prediction  accuracy  for  (a)  TCP  download  throughput  and  (b)  Google 
fetch  time  over  all  trials  on  all  official  APs  at  their  respective  hotspots.  Note  the  logarith¬ 
mic  scale  on  the  x-axis. 

We  simulate  these  scenarios  using  our  measurement  study  as  ground  truth.  That  is, 
we  assume  that  after  the  user  selects  an  AP  s  to  use,  actual (s)  is  equal  to  one  of  our 
measurements  of  s.  We  evaluate  performance  over  all  our  measurement  trials.  To  simulate 
the  predict(s)  that  would  be  generated  by  Wifi-Reports,  we  assume  that  all  measurement 
trials  except  those  for  APs  currently  under  consideration,  are  previously  submitted  reports. 
The  reports  for  s  are  summarized  to  generate  predict(s).  This  assumption  implies  that 
reports  are  generated  by  users  that  visit  locations  and  select  APs  in  a  uniformly  random 
manner.  This  is  more  likely  to  be  the  case  when  there  are  not  yet  enough  reports  in  the 
system  to  generate  any  predictions.  By  counting  devices  associated  with  each  AP  in  our 
measurement  study,  we  observed  that  some  users  do  currently  use  suboptimal  APs.  Thus, 
we  believe  that  such  reports  would  be  obtained  when  bootstrapping  new  APs  in  Wifi- 
Reports. 

Prediction  accuracy.  Figure  4.5  shows  CDFs  of  prediction  accuracy  over  all  trials  of  of¬ 
ficial  hotspot  APs  for  TCP  download  throughput  and  Google  response  time.  The  x-axis  in 
each  graph  shows  the  ratio  of  the  predicted  value  over  the  actual  achieved  value.  Values  at 
1  are  predicted  perfectly,  values  less  than  1  are  underestimates,  and  values  more  than  1  are 
overestimates.  We  compare  three  approaches  for  generating  summary  statistics,  history- 
oracle  shows  the  accuracy  we  would  achieve  if  each  summary  summarizes  only  reports 
taken  at  the  same  hotspot  location  as  the  location  under  consideration;  this  requires  an  “or¬ 
acle”  because  we  would  not  automatically  know  the  logical  location  where  measurements 
are  taken  in  practice.  wifi-reportS  shows  the  accuracy  when  using  Wifi-Reports’  SNR  fil¬ 
ter  before  summarizing  reports  (see  Section  4.4).  history-all  shows  the  accuracy  when  we 
summarize  all  reports  to  generate  a  prediction,  regardless  of  the  location  where  they  were 
taken  (e.g.,  even  if  the  user  is  at  Starbucks,  the  prediction  includes  reports  of  the  same  AP 
taken  across  the  street). 
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In  this  graph,  we  focus  on  official  APs,  where  we  are  sure  to  have  some  measurements 
in  the  0%  loss  region,  to  better  illustrate  the  impact  of  different  channel  conditions.  Users 
in  this  scenario  are  more  likely  to  desire  a  comparison  of  the  0%  loss  predictions  rather 
than  predictions  in  all  three  wireless  channel  conditions  since  they  are  choosing  where  to 
go.  If  an  association  or  connection  fails,  we  mark  that  trial  as  having  0  throughput  and 
infinite  response  time.  Recall  that  the  summary  function  is  median. 

The  graphs  show  that  history-all  underestimates  TCP  bandwidth  and  overestimates 
Google  fetch  time  more  often  than  history-oracle.  This  is  because  by  including  reports 
taken  in  the  intermediate  and  near- 100%  loss  regions,  the  median  will  generally  be  lower. 
In  contrast,  wifi-reportS  performs  about  as  accurately  as  history-oracle,  demonstrating 
that  our  SNR  filter  works  well  when  we  have  some  measurements  in  the  0%  loss  region. 
Furthermore,  we  note  that  at  least  75%  of  predictions  for  both  metrics  are  within  a  fac¬ 
tor  of  2  of  the  achieved  value,  while  Figure  4.2  shows  that  the  difference  in  the  median 
throughputs  and  response  times  of  official  APs  can  be  up  to  50  x  and  10  x,  respectively. 
Therefore,  most  predictions  are  accurate  enough  to  make  correct  relative  comparisons. 

Ranking  accuracy.  We  now  examine  the  scenario  when  a  user  is  choosing  between 
APs  at  a  single  location.  Figure  4.6(a)  and  (b)  show  box-plots  of  achieved  throughput 
and  response  time,  respectively,  when  using  one  of  several  AP  selection  strategies  to  try 
to  achieve  the  best  performance  at  each  location,  best-open  simulates  Virgil  [122],  an 
algorithm  that  associates  with  and  probes  all  open  APs  before  selecting  the  best  one.  best- 
snr  simulates  the  most  common  algorithm  of  picking  the  AP  with  the  highest  SNR  value. 
This  algorithm  works  well  when  wireless  channel  quality  is  the  limiting  factor,  official 
simulates  using  the  “official”  AP  of  each  location.  We  expect  this  algorithm  to  work  well 
since  we  showed  in  Section  4.1  that  the  official  AP  is  the  best  at  most  locations.  Obviously 
this  approach  would  not  work  at  locations  without  an  official  AP.  history-all  simulates 
Wifi-Reports  without  the  SNR  filter,  wifi-reports  simulates  Wifi-Reports,  history-all 
and  wifi-reports  only  generate  a  prediction  for  an  AP  if  we  have  at  least  2  reports  to 
summarize;  if  no  predictions  for  any  AP  are  generated,  they  fall  back  to  selecting  the 
official  AP.  Finally,  optimal  shows  the  best  performance  achievable. 

best-open  performs  the  worst  overall,  failing  to  achieve  any  connections  at  tullys  1 , 
Starbucks  1 ,  and  cafeontheave  since  no  open  APs  were  visible,  best-open  performs 
better  than  all  other  algorithms  only  at  yunnie,  where  most  of  the  APs  were  open.  We 
note  that  best-open  is  qualitatively  different  than  the  other  selection  algorithms  because 
it  cannot  select  any  closed  AP;  we  include  it  only  to  demonstrate  that  restricting  the  choice 
of  APs  to  open  ones  often  results  in  substantially  suboptimal  performance.  Furthermore, 
best-open  also  has  more  overhead  (linear  in  the  number  of  open  APs  visible)  than  the 
others  because  it  must  actively  test  each  AP. 


123 


Figure  4.6:  (a)  Box-plot  of  achieved  TCP  download  throughput  when  using  each  of  five 
AP  selection  algorithms  at  each  location.  Note  the  logarithmic  scale.  Missing  boxes 
for  the  best-open  algorithm  are  at  0.  (b)  Box-plot  of  the  achieved  response  time  of 
http  :  /  /www .  google  .  com  using  each  of  five  AP  selection  algorithms  at  each  loca¬ 
tion.  The  whiskers  that  extend  to  the  top  of  the  graph  actually  extend  to  infinity  (i.e.,  the 
fetch  failed),  missing  boxes  for  the  best-open  algorithm  are  also  at  infinity.  Each  group 
of  boxes  are  ordered  in  the  same  order  as  the  key  at  the  top. 


history-all  again  demonstrates  the  need  for  the  SNR  filter.  Without  the  SNR  filter, 
Wifi-Reports  would  achieve  poorer  performance  than  official  or  best-snr  at  least  25%  of 
the  time  at  tullys  1 ,  trabant,  and  cafeontheave. 

In  contrast,  wifi-reportS  achieves  performance  closest  to  optimal  for  both  metrics  in  all 
cases  except  for  two.  It  achieves  worse  TCP  throughput  than  best-open  once  at  yunnie 
and  worse  response  time  than  best-snr  or  official  once  at  cafeontheave.  In  each  of 
these  cases,  the  AP  chosen  by  wifi-reportS  experienced  an  association  or  DHCP  failure. 
However,  a  real  client  would  quickly  fall  back  to  the  second  best  AP  chosen  by  wifi- 
reports,  which  was  the  optimal  one.  Furthermore,  wifi-reportS  is  able  to  achieve  higher 
bandwidth  more  of  the  time  than  all  other  algorithms  at  yunnie  and  Starbucks  1  and  better 
response  time  more  of  the  time  than  all  other  algorithms  at  tullys  1  and  cafeontheave. 
Thus,  it  performs  strictly  better  in  more  locations  when  compared  with  each  of  the  other 
approaches  individually. 

Finally,  we  note  that  unlike  all  other  approaches,  Wifi-Reports  enables  users  to  rank 
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mean 

min 

max 

std  dev 

description 

Server 

58.918 

33.18 

421.26 

59.056 

generate  key 

Server 

3.979 

3.87 

6.29 

0.222 

sign 

Client 

95.517 

18.00 

560.45 

47.364 

generate  key 

Client 

0.150 

0.14 

22.21 

0.222 

verify 

Client 

0.058 

0.03 

1.43 

0.134 

unblind 

Client 

0.006 

0.00 

1.88 

0.027 

hash 

Client 

0.003 

0.00 

1.88 

0.019 

blind 

Table  4.1:  Microbenchmarks  of  cryptographic  processing  times.  All  keys  are  1024  bit 
RSA  keys  and  SHA-512  is  used  as  the  hash  function.  All  values  in  milliseconds  with  a 
resolution  of  10  microseconds.  1000  trials  were  executed. 

APs  that  are  nearby  but  not  visible.  This  is  useful  when  users  are  willing  to  move  to  obtain 
better  connectivity. 


4.5.2  Report  Protocol  Performance 

We  implemented  our  reporting  protocol  (Section  4.3)  in  software  to  evaluate  its  practical¬ 
ity.  We  present  measurements  of  its  processing  time,  total  token  fetch  time,  and  message 
volume  using  workloads  derived  from  actual  AP  lists.  We  focus  on  the  token  generation 
phase  (GenToken)  since,  given  a  desired  level  of  location  privacy,  its  performance  de¬ 
pends  on  actual  densities  of  APs.  The  report  submission  phase  (SubmitReport)  runs  in 
constant  time  per  report  and  uses  standard  fast  RSA  primitives. 

Setup.  We  emulate  a  client  that  obtains  the  right  to  report  on  APs  while  at  home  (e.g., 
before  or  after  traveling).  Our  client  has  a  2.0  GHz  Pentium  M  and  our  account  authority 
server  used  one  3.4GHz  Xeon  processor  (the  software  is  single  threaded).  Both  run  Linux 
and  all  cryptography  operations  used  openssl  0.9.8.  The  bottleneck  link  between  the  client 
and  server  is  the  client’s  cable  Internet  connection  (6  Mbps  down,  768  kbps  up).  The  round 
trip  time  from  client  to  server  is  144  ms. 

Processing  time.  Table  4. 1  presents  microbenchmarks  of  each  step  of  the  protocol.  All 
times  are  in  milliseconds.  The  most  heavyweight  steps  are  the  generation  of  1024  bit  RSA 
keys  by  both  the  client  (Kij)  and  server  (Mj).^°  However,  both  keys  can  be  generated 
anytime  beforehand  so  these  operations  need  not  be  executed  inline  in  the  GenToken 

'®The  standard  deviation  for  key  generation  is  high  because  the  algorithm  has  a  random  number  of  itera¬ 
tions. 
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protocol.  The  remaining  steps  must  happen  inline,  but  have  very  low  processing  times.  A 
server  can  sign  a  blinded  message  in  under  4  ms,  so  it  can  process  about  250  tokens  per 
second,  while  a  client  can  perform  the  verification  and  unblinding  steps  in  roughly  0.2  ms, 
or  5000  times  per  second. 

Token  fetch  time.  A  user  who  wants  to  obscure  his  locations  within  a  region  must  perform 
GenToken  on  all  APs  in  that  region.  Figure  4.7  shows  the  end-to-end  time  to  fetch  tokens 
for  all  APs  in  each  of  the  ten  cities  that  JiWire  [85]  reports  to  have  the  most  APs  (as  of 
November  15,  2008).  JiWire  lists  commercial  APs  that  service  providers  or  users  have 
manually  added,  which  parallels  how  most  APs  are  added  to  Wifi-Reports.  Nonetheless, 
some  commercial  hotspots  may  not  be  listed  by  JiWire,  so  this  graph  serves  to  establish 
a  lower  bound  for  cities  with  many  APs.  Since  a  user  can  fetch  these  tokens  at  any  time 
before  submitting  a  report,  even  the  longest  delay,  5.5  seconds  for  all  of  New  York,  is 
completely  practical.  Even  obtaining  tokens  for  several  cities  at  once  is  practical  since 
each  client  only  does  this  once  in  its  lifetime. 

WiGLE  [167]  is  a  database  of  all  APs  that  war  drivers  have  overheard,  including  both 
commercial  and  private  APs.  Eigure  4.8,  presents  fetch  times  for  all  WiGEE  APs  in  a 
32  km  square  centered  at  each  city.  Since  most  APs  listed  are  not  intended  to  be  used  by  the 
public  (e.g.,  home  APs)  and  WiGEE  does  not  filter  out  erroneous  or  stale  measurements, 
this  graph  serves  as  a  loose  upper  bound  on  fetch  times.  Even  so,  the  worst  fetch  time 
(Seattle)  is  20  minutes.  Since  a  client  can  batch  sig-request  messages  for  multiple 
APs,  a  reasonable  approach  would  be  to  request  all  tokens  and  then  retrieve  them  at  a  later 
time.  In  addition,  by  choosing  a  region  granularity  of  less  than  a  city,  a  client  can  achieve 
much  better  delay  and  still  mask  his  locations  to  a  reasonable  extent.  Eigure  4.9  shows  the 
CDE  of  number  of  WiGEE  APs  in  Ikm^  areas  in  each  of  the  cities.  Most  cells  in  all  cities 
have  fewer  than  188  APs,  which  only  takes  about  1  second  to  fetch,  and  no  cell  has  more 
than  7400,  which  only  takes  about  30  seconds  to  fetch.  Since  commercial  areas  in  most 
cities  are  not  spread  out,  most  will  be  covered  by  a  small  number  of  cells.  Einally,  we  note 
that  the  server  can  parallelize  the  generation  of  each  token  to  improve  performance. 

Message  volume.  A  request  for  tokens  transmits  173  bytes  per  token,  while  the  response 
transmits  529  bytes  per  token.  Therefore,  our  protocol  is  CPU-bound  on  the  server  even 
for  a  client  on  a  cable  modem.  Eor  example,  it  takes  our  client  8.7  minutes  to  send  all 
requests  for  Seattle  APs  on  WiGEE  and  3.4  minutes  to  receive  the  replies  (these  latencies 
are  included  in  the  token  fetch  times  reported  above). 

Admission  rate  and  server  cost.  We  next  estimate  the  rate  at  which  users  can  join  given 
limited  server  resources.  To  simulate  “average”  American  users  joining  the  system,  we 
assume  that  each  user  requests  all  tokens  from  one  of  the  cities  shown  in  Eigure  4.7,  chosen 
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Figure  4.7:  Time  to  aequire  the  right  to  report  on  all  APs  listed  by  JiWire  in  ten  eities. 
The  eities  presented  are  the  ten  with  the  most  APs,  aeeording  to  JiWire  as  of  November 
15,  2008. 


at  random  weighted  by  eaeh  eity’s  population  (aeeording  to  2007  U.S.  eensus  data  [158]). 
While  a  user  may  request  more,  the  authority  rate  limits  eaeh  user  to  prevent  denial-of- 
serviee  attacks. 

Suppose  the  authority  has  x  CPUs.  For  JiWire  APs,  it  can  admit  27,455x  new  users  per 
day.  For  example,  if  the  authority  has  100  CPUs,  it  can  admit  the  entire  population  of  these 
cities  in  5.6  days.  How  much  would  this  overhead  cost  over  a  system  that  stores  reports 
without  privacy?  If  deployed  on  Amazon’s  EC2  [9],  this  would  only  cost  about  0.02  cents 
per  user  for  CPU  and  bandwidth  resources.  For  all  WiGLE  APs,  the  authority  can  admit 
165a;  new  users  per  day  and  the  overhead  cost  would  be  about  2.6  cents  per  user.  This  one¬ 
time  cost  is  a  very  small  fraction  of  the  $5-i-  each  user  would  have  to  spend  to  use  most 
commercial  APs  just  for  one  day.  There  are  also  recurring  costs  incurred  for  computing 
tokens  for  new  APs  that  are  added  and,  if  enabled,  signing  reports  for  rate  limiting  (see  the 
end  of  Section  4.3.3).  However,  these  costs  are  also  trivial.  Eor  example,  even  if  10  new 
hotspots  appear  in  each  city  every  week  and  every  user  submits  10  new  reports  per  week, 
the  recurring  cost  would  only  be  about  0.02  cents  per  user  per  year. 


127 


1200 


CO 

T3 

c 

O 

o 

0) 

0) 

E 


o 

0) 


0 


1  1 

Seattle...-^ 

“ 

Los  Angelesj®^ 

- 

Chicago.>c 

Austin^Jr 

Houston^ 

^Washington 

New  York,X^ 

Atlanta 

_x"San  Antonio 

- 

San  Diego 

_ 1 _ 1 _ 

_i _ 1 _ 1 _ 

0  50000  100000  150000  200000  250000  300000 

Number  of  APs 


Figure  4.8:  Time  to  acquire  the  right  to  report  on  all  APs  listed  by  WiGLE  in  32  km  x 
32  km  squares  centered  on  each  of  ten  cities. 


4.5.3  Resistance  to  Fraud 

Summary  values  are  robust  to  fraudulent  reports  that  try  to  boost  or  degrade  an  AP’s  value 
because  we  use  summary  functions  that  are  resilient  to  outliers.  However,  since  there  is 
variability  in  honest  reports  as  well,  a  small  number  fraudulent  reports  may  still  be  able  to 
degrade  prediction  accuracy,  e.g.,  by  shifting  the  median  higher  or  lower. 

Setup.  We  consider  the  same  scenario  as  in  Section  4.5.1.  To  evaluate  the  extent  that 
fraudulent  reporting  can  degrade  accuracy,  we  simulate  an  adversary  that  tries  to  boost 
the  predicted  TCP  download  throughput  of  an  AP  by  submitting  reports  that  claim  the 
AP  achieves  54  Mbps,  the  maximum  theoretically  possible  in  802.  llg.  In  this  evaluation 
users  only  consider  each  AP’s  0%-loss  summary,  so  we  assume  that  each  adversarial  user 
submits  one  report  with  SNR  in  the  middle  of  this  range.  Although  he  could  submit  more, 
they  would  not  change  the  summary  since  only  one  report  per  user  is  used.  We  vary 
the  power  of  the  adversary  by  varying  the  number  of  users  that  collude  to  submit  these 
fraudulent  reports.  A  typical  AP  would  also  have  many  honest  reports.  Therefore,  we 
simulate  each  AP  with  100  reports  total:  x  are  the  fraudulent  reports  described  above  and 
100  —  X  are  honest  reports  that  are  randomly  sampled  (with  replacement)  from  our  ~10 
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APs  per  square  kilometer 


Figure  4.9:  CDF  of  the  number  of  APs  listed  by  WiGLE  in  eaeh  1  km^  region  of  a  32  km 
X  32  km  grid  centered  on  each  of  ten  cities. 


actual  measurements  per  AP.  Note  that  even  if  the  total  number  of  reports  is  different,  our 
results  still  hold  on  expectation  if  the  ratio  of  fraudulent  to  total  reports  remains  the  same. 
The  remainder  of  our  simulation  setup  is  identical  to  Section  4.5.1.  For  comparison  to 
Figure  4.5(a),  we  again  focus  on  official  APs. 

Accuracy.  Figure  4.10  shows  Wifi-Reports’  prediction  accuracy  on  official  APs  as  we 
vary  the  percentage  of  fraudulent  reports.  Negligible  degradation  of  accuracy  is  observed 
when  up  to  10%  of  reports  are  fraudulent.  Even  with  30%  of  fraudulent  reports,  most 
predictions  are  still  correct  within  a  factor  of  2.  However,  when  50%  of  reports  are  fraud¬ 
ulent,  most  predictions  are  gross  overestimates.  This  result  is  expected  since  the  median 
function  is  not  robust  to  50%  or  more  outliers  larger  than  the  actual  median. 

Discussion.  We  note  that  even  if  an  adversary  is  successful  in  luring  honest  clients  to  a 
poor  AP,  those  clients  will  submit  reports  that  correct  the  summary  statistics.  Successful 
fraud  attacks  that  degrade  a  good  AP’s  reputation  (or  contract  its  0%-loss  SNR  range) 
are  harder  to  correct  because  honest  users  may  be  dissuaded  from  using  that  AP.  However, 
since  cost,  venue,  and  other  external  factors  will  influence  selections  in  practice,  we  believe 
some  honest  users  will  eventually  report  on  these  APs  and  correct  their  summary  statistics. 
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Figure  4.10:  CDF  of  prediction  accuracy  for  TCP  download  throughput  of  all  official 
APs  at  their  respective  hotspots.  We  vary  the  percentage  of  fraudulent  reports  that  claim 
throughput  is  54Mbps.  Note  the  logarithmic  scale  on  the  x-axis. 

4.6  Related  Work 


Wifi-Reports  is  related  to  four  areas  of  previous  work:  recommender  systems,  collabora¬ 
tive  sensing,  AP  selection,  and  electronic  cash/secure  voting  protocols. 

Recommender  systems.  Previous  proposals  for  reputation-based  AP  location  systems, 
such  as  Salem  et  al.  [141],  do  not  protect  contributors’  location  privacy.  Moreover,  Salem 
et  al.’s  protocol  assumes  APs  can  predict  their  performance  and  it  does  not  address  vary¬ 
ing  wireless  channel  conditions.  Of  course,  having  users  report  on  items  or  services  to 
ascertain  their  value  is  a  well  known  idea  (e.g.,  for  a  survey  see  [5]).  For  example.  Broad¬ 
band  reports  [37]  rates  ISPs  using  user-reported  speed  tests  (e.g.,  [149])  that  measure  their 
back-haul  capacities.  However,  Broadband  reports  takes  few  measures  to  prevent  fraud. 
This  may  be  because,  unlike  the  identity  of  an  AP,  it  is  difficult  to  forge  the  IP  address  that 
identifies  the  ISP  in  a  speed  test.  Furthermore,  it  is  relatively  easy  to  limit  sybil  attacks  [52] 
because  a  user  is  identified  by  an  IP  address,  which  is  hard  to  spoof  while  maintaining  the 
necessary  TCP  connection  for  reporting. 

Some  recommendation  systems  use  collaborative  filtering  (CF)  (e.g.,  [162,  176])  to 
identify  users  that  submit  many  bad  reports.  However,  these  techniques  require  that  all 
reports  from  the  same  user  are  linked  and  thus  do  not  protect  privacy,  which  is  important 
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when  location  information  is  at  stake.  Some  proposed  CF  techniques  can  limit  the  ex¬ 
posure  of  this  information  by  using  secure  multi-party  voting  [38,  39].  However,  these 
techniques  require  all  users  to  be  simultaneously  online  to  update  summary  statistics,  and 
thus  are  impractical  for  services  that  have  many  users  and  continuous  submission  of  re¬ 
ports. 

Collaborative  sensing.  A  number  of  recent  proposals  use  mobile  devices  as  collaborative 
sensor  networks  (e.g.,  [96,  4]),  but  they  do  not  address  the  unique  challenges  of  AP  mea¬ 
surement  and  reporting.  Anonysense  [45]  is  one  such  platform  that  ensures  that  reports  are 
anonymous  by  using  a  mix  network.  However,  Anonysense  relies  on  a  trusted  computing 
base  (TCB)  to  prevent  fraudulent  reports  and  cannot  prevent  non-software  based  tamper¬ 
ing  (e.g.,  disconnecting  a  radio  antenna)  nor  fraudulent  reports  from  clients  that  collude 
with  APs  without  a  TCB.  These  attacks  are  simple  to  carry  out  to  modify  wireless  mea¬ 
surements.  Nonetheless,  the  Wifi-Reports  measurement  client  could  also  leverage  a  TCB 
to  mitigate  fraud  even  more. 

[122,  151,  160]  argue  for  metrics  other  than  signal  strength  for  ranking  access  points, 
but  only  consider  metrics  that  can  be  instantaneously  measured  by  a  single  client.  We 
showed  in  Section  4.5  that  leveraging  historical  information  out-performs  direct  measure¬ 
ment  [122]  because  it  isn’t  always  possible  to  test  an  AP  before  use.  In  addition,  Wifi- 
Reports  is  the  only  system  that  enables  users  to  evaluate  APs  that  are  not  in  range,  such  as 
when  searching  for  an  AP  in  a  hotspot  database.  Nonetheless,  our  work  is  complementary 
to  [151]  and  [160],  which  can  better  estimate  the  quality  of  the  wireless  channel  when  it  is 
the  performance  bottleneck. 

Electronic  cash  and  secure  voting.  Wifi-Reports  uses  blind  signatures  in  a  manner 
similar  to  well-known  electronic  cash  [42,  41]  (e-cash)  and  secure  voting  [60]  (e- voting) 
protocols.  However,  unlike  traditional  e-cash  protocols  where  a  user  has  multiple  tokens 
that  can  be  spent  on  any  service,  a  user  of  our  reporting  protocol  has  a  single  token  per 
service  that  can  only  be  used  for  that  service.  Traditional  e-voting  protocols  typically 
assume  that  all  users  vote  (e.g.,  report)  on  all  candidates  (e.g.,  APs)  before  tallying  the 
votes,  whereas  reports  are  continuously  tallied  in  Wifi-Reports  but  a  precise  count  is  not 
necessary.  As  a  consequence,  our  reporting  protocol  is  simpler  than  traditional  e-cash 
and  e-voting  protocols,  but,  like  these  protocols,  it  relies  on  an  account  authority  and 
distributed  talliers  (e.g.,  report  databases)  to  prevent  attacks. 
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4.7  Summary  and  Discussion 


This  chapter  presented  Wifi-Reports,  a  service  that  improves  AP  selection  by  leveraging 
historical  information  about  APs  contributed  by  users.  A  system  like  Wifi-Reports  is  im¬ 
portant  because  our  measurement  study,  the  first  of  commercial  APs,  showed  that  there  is 
substantial  diversity  in  AP  performance,  even  among  those  close  by.  Wifi-Reports  can  han¬ 
dle  reports  submitted  at  different  locations,  protects  users’  location  privacy,  and  is  resilient 
to  a  small  fraction  of  fraudulent  reports.  The  central  contribution  of  Wifi-Reports’  design 
is  to  demonstrate  how  crowd-sourced  LBSes  can  make  user-submitted  reports  unlinkable, 
yet  also  ensure  that  each  user  has  limited  influence  in  summarized  results. 


4.7.1  Discussion 

Although  we  presented  our  reporting  protocol  in  the  context  of  a  hotspot  directory  service, 
it  is  applicable  to  crowd-sourced  recommender  systems  more  generally.  The  protocol  can 
be  applied  to  other  collaborative  reporting  services  by  replacing  the  set  of  APs,  S,  with 
the  set  of  items  being  reported  on.  Nonetheless,  we  note  that  there  are  two  important 
limitations.  First,  the  protocol’s  practicality  is  dependent  on  our  ability  to  group  items 
into  subsets  that  are  reasonably  small  and  not  revealing.  Second,  the  protocol  can  not  be 
applied  when  collaborative  filtering  is  required. 

Reasonably  sized  subsets.  Users  in  Wifi-Reports  can  fetch  tokens  in  a  practical  amount 
of  time  because  we  presumed  that  they  are  willing  to  reveal  a  coarse  grain  region  that 
they  have  visited  (e.g.,  a  city)  and  that  each  of  these  regions  does  not  contain  more  than  a 
million  APs.  If  the  set  of  items  that  a  user  has  to  fetch  to  obtain  sufficient  privacy  is  larger 
than  several  million,  then  the  cost  of  generating  tokens  becomes  prohibitive.  Therefore, 
an  important  challenge  when  applying  this  protocol  to  other  crowd-sourced  recommender 
systems  is  how  to  subdivide  the  set  of  items  into  subsets  of  reasonable  size  and  that  have 
appropriate  privacy  semantics. 

Collaborative  filtering.  In  contrast  to  plain  query-based  LBSes  and  crowd-sourced  LB¬ 
Ses,  collaborative  filtering  (CF)  services  help  users  by  finding  users  with  similar  interests. 
For  example,  a  dating  site  might  try  to  match  users  that  have  been  to  similar  places.  CF 
services  that  match  users  based  on  location  history  actually  need  to  link  a  user’s  location 
samples  together  to  function  using  existing  collaborative  filtering  techniques.  For  exam¬ 
ple,  techniques  to  prevent  sybil  attacks  and  fraud  in  such  systems,  such  as  DSybil  [176], 
actually  rely  on  tracking  the  history  of  each  user’s  votes  or  reports.  Although  some  pro¬ 
posed  CF  techniques  for  peer-to-peer  systems  can  limit  the  exposure  of  user  histories  by 
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using  dimensionality  reduction  and  secure  multi-party  voting  [38,  39],  these  techniques 
are  difficult  to  apply  when  clients  which  are  not  always  online.  Thus,  designing  appro¬ 
priate  privacy  models  and  mechanisms  for  CF  services  is  a  final  important  area  of  future 
work. 


133 


134 


Chapter  5 

Conclusions  and  Future  Work 


Remember  that  the  primary  threat  to  location  privacy  comes  from  the  collection  of  lo¬ 
cation  traces,  i.e.,  a  set  of  location  samples  known  to  be  from  the  same  device  or  user. 
Eavesdroppers  and  crowd-sourced  LBSes  can  collect  these  traces  when  we  use  existing 
wireless  protocols  because  they  can  link  a  user’s  identity  to  the  locations  that  he  visits. 
We  conclude  this  dissertation  with  a  summary  of  how  our  work  limits  the  ability  of  these 
parties  to  link  identities  to  locations.  We  then  discuss  some  open  problems  that  remain. 


5.1  Summary 

This  dissertation  made  the  following  thesis:  Existing  protocols  and  techniques  that  wire¬ 
less  devices  use  to  discover  and  communicate  with  each  other  pose  risks  to  users  ’  location 
privacy.  It  is,  however,  possible  to  redesign  these  protocols  and  techniques  to  substantially 
mitigate  location  privacy  threats  without  degrading  their  functionality  or  practicality. 

Recall  that  the  usage  model  of  wireless  protocols  such  as  802.11  typically  has  four 
phases:  select,  rendezvous,  communicate,  and  report.  Our  work  shows  that  existing 
link  layer  protocols  reveal  implicit  identifiers  during  the  rendezvous  and  communication 
phases  even  when  pseudonym  schemes  to  mask  unique  identifiers  in  those  protocols  (e.g., 
MAC  addresses  in  802.11)  are  employed.  In  addition,  we  showed  that  crowd-sourced 
Wi-Fi  directory  services  are  highly  useful,  but  currently  do  not  protect  the  anonymity  of 
user  reports  because  they  need  to  limit  the  number  of  fraudulent  reports  that  malicious 
users  can  submit.  Thus,  these  services  can  currently  link  our  identities  to  our  locations 
during  the  reporting  phase.  Although  previous  work  showed  how  using  coarse  grain  or 
noisy  location  queries  can  be  used  to  conceal  our  identity  during  the  selection  phase,  these 
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techniques  can  not  be  applied  to  crowd-sourced  LBSes. 

In  light  of  these  shortcomings,  we  showed  that  we  can  build  link  layer  protocols  that 
conceal  all  transmitted  bits  with  comparable  efficiency  and  functionality  as  existing  pro¬ 
tocols.  For  example,  SlyFi  can  replace  802.11  with  very  little  degradation  in  performance 
if  both  ends  of  a  communication  support  it.  Concealing  all  transmitted  bits  eliminates 
all  explicit  identifiers  and  makes  it  substantially  more  difficult  for  eavesdroppers  to  detect 
implicit  identifiers  during  the  rendezvous  and  communication  phases.  Furthermore,  we 
showed  that  we  can  build  location-based  recommender  systems,  such  as  Wi-Fi  directory 
services,  that  preserve  the  anonymity  of  user-submitted  reports  and  limit  the  number  of 
fraudulent  reports  a  single  user  can  submit,  thereby  concealing  our  identity  during  the 
reporting  phase.  Wifi-Reports  shows  that  a  privacy-preserving  hotspot  directory  service 
would  be  practical  today. 


5.2  Contributions 

This  dissertation  made  contributions  in  answering  three  principle  questions: 

Are  simple  pseudonym  protocols  sufficient  to  prevent  location  tracking  by  No 
eavesdroppers? 

Can  we  build  complete  and  practical  link-layer  protocols  that  conceal  all  Yes 
identifiers? 

Can  we  build  practical  crowd-sourced  LBSes  for  wireless  service  location  Yes 
in  a  manner  than  preserves  both  privacy  and  accountability? 

5.2.1  Implicit  Identifier  Tracking  Threats  in  Practice 

Central  Insight.  To  our  knowledge,  we  are  the  first  to  show  with  empirical  evidence 
that  design  considerations  beyond  eliminating  explicit  identifiers,  such  as  unique  MAC 
addresses,  must  be  addressed  to  protect  anonymity  in  wireless  networks.  This  is  because, 
even  without  a  unique  address,  other  characteristics  of  users’  802.11  traffic  can  identify 
them  implicitly  and  track  them  with  high  accuracy.  An  example  of  such  an  implicit  iden¬ 
tifier  is  the  SSID  (i.e.,  network  name)  of  access  points  that  his  laptop  tries  to  discover. 
In  a  population  of  several  hundred  users,  the  set  of  these  SSIDs  might  be  unique  to  one 
individual;  thus,  the  mere  observation  of  this  IP  address  would  indicate  the  presence  of 
that  user. 
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Key  Results.  We  identified  four  previously  unrecognized  implicit  identifiers  that  re¬ 
main  even  when  previously  proposed  MAC  address  pseudonym  schemes  are  applied:  net¬ 
work  destinations,  network  names  advertised  in  802.11  probes,  differing  configurations  of 
802.11  options,  and  sizes  of  broadcast  packets  that  hint  at  their  contents.  The  later  three 
of  these  implicit  identifiers  remain  even  when  link-layer  encryption  is  employed.  Further¬ 
more,  we  developed  an  automated  procedure  to  identify  users.  This  procedure  allows  us  to 
quantify  how  much  information  implicit  identifiers,  both  alone  and  in  combination,  reveal 
about  several  hundred  users  in  three  empirical  802.11  traces.  Our  evaluation  using  this 
technique  shows  that  many  of  these  users  emit  highly  discriminating  implicit  identifiers, 
and,  thus,  even  a  small  sample  of  network  traffic  can  identify  them  more  than  half  (56%)  of 
the  time  in  public  networks,  on  average.  Moreover,  we  will  almost  never  mistake  them  as 
the  source  of  other  network  traffic  (1%  of  the  time).  Since  adversaries  will  obtain  multiple 
traffic  samples  from  a  user  over  time,  this  high  accuracy  in  traffic  classification  enables 
them  to  track  many  users  with  even  higher  accuracy  in  common  wireless  networks.  For 
example,  an  adversary  can  identify  64%  of  users  with  90%  accuracy  when  they  spend  a 
day  at  a  busy  hot  spot  that  serves  25  concurrent  users  each  hour.  Even  if  the  hot  spot 
employed  link- layer  encryption,  31%  of  users  can  be  still  identified  with  90%  accuracy. 

5.2.2  Practical  Identifier-free  Link  Layer  Protocols 

Central  Insight.  To  address  the  implicit  identifier  problem,  we  developed  SlyFi,  a  link 
layer  protocol  that  reveals  no  transmitted  bits  to  eavesdroppers.  The  obvious  difficulty 
with  simply  removing  all  explicit  fields  is  that  they  play  key  roles  in  the  efficient  opera¬ 
tion  of  existing  protocols.  For  example,  a  connection  identifier  allows  a  device  to  decide 
whether  it  is  the  destination  of  a  message  by  using  a  simple  compare  operation.  Our 
central  contribution  is  a  set  of  two  efficient  primitives  for  constructing  service  discovery 
protocols  and  subsequent  data  transfer  protocols  that  conceal  all  transmitted  bits.  These 
primitives  leverage  assumptions  about  the  rendezvous  and  communication  phases  of  the 
wireless  protocol  to  synchronize  cryptographically  secure  pseudorandom  sequences.  As 
a  consequence,  in  both  cases  a  device  can  determine  whether  it  is  the  recipient  of  a  mes¬ 
sage  with  lightweight  table  look-ups.  We  demonstrate  that  all  wireless  protocol  features 
that  rely  on  identifiers — service  discovery,  packet  filtering,  and  address  binding — can  be 
supported  without  exposing  them. 

Key  Results.  We  have  implemented  SlyFi  on  commodity  802.11  NICs  and  our  exper¬ 
iments  show  that  SlyFi’s  performance  impact  is  modest,  as  it  uses  only  cryptographic 
operations  already  used  by  WPA.  In  particular,  we  showed  that  a  SlyFi  client  can  discover 
and  associate  with  services  even  faster  than  802.11  with  WPA  using  PSK  authentication. 
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SlyFi’s  overhead  results  in  a  throughput  degradation  that  is  only  slightly  greater  than  that 
of  WPA  with  CCMP  encryption  (10%  vs.  3%). 


5.2.3  Privacy-preserving  Crowd-sourced  Location-based  Systems 


Central  Insight.  SlyFi  only  protects  communication  sent  between  devices  that  already 
trust  each  other.  To  support  improved  discovery  of  new  public  wireless  services,  such 
as  802.11  APs,  we  need  hotspot  directories  that  accept  user  submitted  reports  and  sum¬ 
marize  them  (e.g.,  a  crowd-sourced  LBS).  For  example,  if  users  report  the  bandwidth  of 
APs  that  they  use,  the  hotspot  directory  can  list  the  median  bandwidth  of  all  APs  to  help 
users  select  among  them.  However,  in  order  to  preserve  location  privacy,  a  user  should  not 
have  to  reveal  that  he  used  an  AP  to  report  on  it.  Otherwise  he  would  implicitly  reveal  a 
location  that  he  visits.  At  the  same  time,  however,  a  few  users  should  not  be  able  to  sig¬ 
nificantly  skew  an  AP’s  summary  statistics  because  some  may  have  an  incentive  to  submit 
fraudulent  reports,  e.g.,  to  promote  APs  that  they  own.  Our  central  contribution  is  a  report 
submission  protocol  that  tolerates  a  few  misbehaving  users  and  does  not  require  the  disclo¬ 
sure  of  location  related  information  to  anyone,  including  the  LBS.  Our  protocol  leverages 
blind  signatures  to  ensure  that  the  service  can  regulate  the  number  of  reports  that  each 
user  submits,  but  cannot  distinguish  one  user’s  reports  from  another’s.  To  demonstrate 
the  practicality  of  this  protocol  we  presented  the  design,  implementation,  and  evaluation 
of  Wifi-Reports,  a  hotspot  directory  service  that  implements  this  protocol.  Although  we 
presented  this  reporting  protocol  in  the  context  of  a  hotspot  directory  service,  it  is  also 
applicable  to  some  other  location-based  collaborative  recommender  systems. 

Key  Results.  We  conduct  the  first  study  that  examine  the  attributes  of  commercial  en¬ 
crypted  and  “pay-for-access”  APs  in  the  wild.  Our  results  suggest  that  hotspot  recom¬ 
mender  systems  would  have  enormous  utility  because  there  is  a  large  range  in  AP  perfor¬ 
mance.  For  example,  different  APs’  median  throughputs  and  response  times  differ  by  up 
to  50  X  and  10  x,  respectively.  We  show  that  Wifi-Reports  can  predict  AP  throughput  and 
response  time  to  within  a  factor  of  2  at  least  75%  of  the  time.  Moreover,  we  show  that 
Wifi-Reports  generates  accurate  summary  statistics  for  each  AP  even  if  10%  of  that  AP’s 
users  collude  to  promote  it. 
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5.3  Future  Work 


A  number  of  important  questions  about  location  privacy  in  the  context  of  wireless  proto¬ 
cols  and  services  remain.  In  this  section,  we  outline  several  open  problems  and  suggest 
some  initial  directions  for  solutions  where  possible. 

5.3.1  Private  Key  Distribution  for  Device  Discovery 

In  both  existing  secure  wireless  protocols  and  in  SlyFi,  an  important  challenge  is  how 
to  bootstrap  the  symmetric  or  public  keys  that  are  necessary  before  two  devices  are  able 
to  rendezvous  and  authenticate  each  other  for  the  first  time.  This  bootstrapping  phase  is 
typically  done  out-of-band  between  the  selection  and  rendezvous  phases  of  the  wireless 
usage  model.  The  two  traditional  classes  of  key  establishment  mechanisms,  pairing  and 
certificates,  can  be  used  in  some  scenarios,  but  may  also  be  insufficient  to  establish  keys 
in  many  useful  service  discovery  settings.  In  this  section,  we  outline  the  challenges  and 
some  initial  solutions  for  key  establishment  protocols  that  conceal  device  identities  [129]. 

Challenges.  Pairing  [152]  refers  to  the  techniques  used  to  establish  keys  on  two  personal 
devices  that  a  user  wants  to  connect  together  (e.g.,  Bluetooth  peripherals).  Pairing  mecha¬ 
nisms  usually  involve  the  physical  exchange  of  some  secret,  such  as  a  verbally  exchanged 
passkey,  or  the  use  of  an  out-of-band  channel,  such  as  direct  physical  contact.  These  mech¬ 
anisms  assume  that  users  of  the  devices  can  identify  them  physically,  which  is  often  not  the 
case  (e.g.,  when  trying  to  find  an  802. 1 1  AP).  Moreover,  all  these  mechanisms  assume  that 
a  client  already  knows  the  specific  service  it  wants  to  discover.  Ironically,  this  assumption 
means  that  to  use  pairing,  users  have  to  discover  services  before  their  devices  can  discover 
them,  which  defeats  the  purpose  of  “automatic”  service  discovery.  Service  discovery  is 
often  useful  because  it  enables  users  to  find  services  they  do  not  yet  know  about  (two  such 
scenarios  are  described  below). 

Public  wireless  services,  such  as  infrastructure  APs,  can  advertise  certificates  signed 
by  trusted  authorities  (e.g.,  VeriSign)  to  prove  their  authenticity  to  clients.  This  is  the 
trust  model  we  use  for  public  hotspots  in  Wifi-Reports.  However,  private  services  can 
not  offer  certificates  to  unknown  clients  without  violating  their  own  privacy.  Similarly, 
clients  can  not  privately  offer  proof  of  identity  before  authenticating  a  service.  Even  pre¬ 
distribution  of  certificates  via  out-of-band  channels  is  difficult  because  mobile  devices  are 
often  disconnected. 

Initial  solutions.  Devices  in  two  mutually  trusted  domains  can  often  assume  bilateral 
trust.  For  example,  if  Alice  and  Bob  are  friends,  they  may  allow  all  their  current  and 
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future  devices  to  discover  each  other.  They  might  naively  try  to  achieve  this  either  by 
sharing  a  single  private  key  among  all  devices  in  one  domain,  or  by  exchanging  all  their 
device  keys.  However,  the  former  approach  compromises  all  the  devices  if  even  one  is 
stolen,  and  the  later  approach  does  not  enable  the  discovery  of  new  devices  that  Alice  and 
Bob  obtain  after  the  key  exchange. 

To  establish  keys  automatically  in  this  scenario,  we  can  leverage  anonymous  identity 
based  encryption  [3]  (AIBE),  a  public  key  encryption  scheme  primarily  used  for  confi¬ 
dential  email.  Using  AIBE,  Alice  can  assign  a  different  private  key  to  each  device  and 
Bob  can  encrypt  a  discovery  message  to  that  device  using  a  human-readable  string  as  the 
encryption  key  and  a  publicly  known  encryption  algorithm.  This  string  is  chosen  based 
on  an  agreed  upon  naming  convention  (e.g.,  Alice. iPhone  can  be  the  encryption  key  for 
Alice’s  iPhone)  but  a  message  encrypted  with  it  hides  both  the  key  and  the  recipient.  A 
trusted  authority  provides  Alice  with  the  private  decryption  key,  ensuring  that  only  she  can 
decrypt  messages  encrypted  with  keys  beginning  with  Alice  (i.e.,  a  unique  user  name  she 
uses  with  this  authority).  The  authority  also  publicly  publishes  the  encryption  algorithm, 
which  is  the  same  for  all  its  users  (i.e.,  the  same  algorithm  is  used  whether  the  key  is 
Alice. iPhone,  or  Alice. Zune,  or  Charlie. iPhone,  etc.). 

Eor  example,  suppose  Bob  and  Alice  each  purchase  a  new  iPhone,  each  preloaded  with 
AIBE  private  keys.  Bob  configures  his  iPhone  to  trust  (the  string)  Alice  and  Alice  config¬ 
ures  hers  to  trust  Bob  (e.g.,  by  adding  each  string  to  their  respective  address  books).  If 
Bob  and  Alice  are  nearby,  their  iPhones  could  discover  each  other  and  use  802. 1 1  to  con¬ 
nect  their  calls,  without  first  needing  to  exchange  keys  (indeed.  Bob  need  not  even  know 
that  Alice  has  an  iPhone).  To  do  this,  Bob’s  iPhone  simply  sends  a  discovery  message 
encrypted  using  the  string  Alice. iPhone  and  only  Alice’s  iPhone  can  receive  it. 

Two  mutually  trusted  devices  may  also  be  willing  to  trust  each  other’s  relations.  Eor 
example,  Bob’s  iPhone  may  permit  all  802.11  APs  that  Alice’s  iPhone  uses  to  discover 
it.  Similarly,  some  of  these  APs  may  permit  Alice’s  friends  to  discover  them.  Bob  might 
naively  attempt  to  bootstrap  keys  for  these  APs  by  having  Alice  give  him  all  their  public 
keys.  However,  this  approach  does  not  work  for  new  APs  that  Alice  uses  after  this  key 
exchange,  and  it  forces  Alice  to  reveal  all  her  AP  relations  to  Bob. 

Instead,  we  can  leverage  a  private  social  proximity  test  [58]  to  automatically  establish 
keys  in  this  scenario.  This  test  enables  Bob’s  iPhone  to  send  a  message  that  can  only  be 
read  by  devices  that  Alice  has  allowed  to  trust  her  friends,  without  having  to  explicitly  tell 
Bob  about  any  of  them.  Note  that  Bob  will  still  learn  about  Alice’s  relationship  with  an 
AP  when  he  discovers  it.  However,  Alice,  who  must  agree  to  use  this  mechanism,  may  be 
willing  to  permit  this  revelation. 
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Discussion.  Although  neither  of  these  mechanisms  provide  absolute  confidentiality  as 
they  require  additional  trust  assumptions,  they  are  only  used  when  devices  attempt  to  dis¬ 
cover  others  with  which  they  have  not  established  keys.  A  symmetric  key  can  then  be 
exchanged  for  subsequent  rendezvous  attempts  using  SlyFi.  Thus,  an  important  research 
challenge  is  to  determine  how  to  limit  the  use  of  these  mechanisms  to  those  circumstances 
for  which  they  are  truly  needed.  For  example,  in  the  case  of  802.11,  clients  generally 
prefer  known  APs  to  unknown  ones.  Thus,  these  mechanisms  are  not  needed  when  known 
APs  are  present. 

Finally,  the  rapid  evolution  of  service  discovery  scenarios  means  that  we  do  not  yet 
have  a  clear  picture  of  all  use  cases.  Emerging  scenarios  may  require  access  based  on 
capabilities  that  these  mechanisms  do  not  support.  For  example,  a  wireless  network  may 
want  to  be  visible  only  to  clients  in  a  specific  physical  area.  Private  key  establishment 
mechanisms  for  these  scenarios  are  an  important  area  of  future  work. 


5.3.2  Concealing  Higher-layer  Explicit  Identifiers 

In  this  dissertation,  we  focused  on  concealing  link-layer  identifiers  and  those  exposed  to 
LBSes.  However,  identifiers  that  remain  in  IP  and  application  layer  protocols  may  still  be 
observed  by  some  entities  during  the  communication  phase  of  the  wireless  usage  model. 
The  most  prominent  example  of  these  identifiers  are  application-level  service  identifiers 
used  in  application-level  service  discovery.  Windows,  Mac  OS  X,  and  Linux  operating  sys¬ 
tems  use  service  discovery  protocols  such  as  NetBIOS,  UPnP  SSDP,  SEP,  and  Multicast 
DNS  (mDNS)  to  discover  other  devices  and  services  on  the  same  local  network.  User- 
level  applications  such  as  iTunes  and  iChat  use  service  discovery  to  find  other  instances 
of  the  same  application  on  the  local  network.  These  protocols  function  in  the  same  way 
as  link-layer  rendezvous  protocols  (i.e.,  using  either  probes  or  announcements).  Although 
eavesdroppers  that  are  not  on  an  encrypted  local  network  can  not  observe  such  identifiers, 
users  may  not  always  trust  all  devices  on  the  local  network  either  (e.g.,  at  a  hotspot).  Eor- 
tunately,  the  same  primitive  we  used  to  conceal  identifiers  in  link-layer  rendezvous  (Tryst) 
can  be  used  to  conceal  identifiers  in  higher-layer  discovery  protocols.  Doing  so  is  mostly 
an  engineering  challenge.  However,  there  is  also  a  research  challenge  in  bootstrapping  the 
symmetric  keys  necessary  to  use  Tryst.  This  is  a  more  important  challenge  for  applica¬ 
tion  layer  discovery  protocols  because  they  are  often  used  to  support  “zero-configuration” 
networking,  and  requiring  manual  key  exchange  would  hinder  ease-of-use.  We  proposed 
some  initial  solutions  to  the  key  exchange  problem  above. 


141 


5.3.3  Concealing  Physical  Layer  Implicit  Identifiers 

In  addition  to  higher-layer  explicit  identifiers,  lower-layer  implicit  identifiers  at  the  physi¬ 
cal  layer  that  are  exposed  during  the  rendezvous  and  communication  phases  of  the  wireless 
usage  model  may  be  detected  by  adversaries  with  special  equipment  [16,  36,  70,  143].  We 
believe  that  such  equipment,  such  as  signal  analyzers  that  cost  tens  of  thousands  of  dol¬ 
lars,  are  out  of  reach  of  casual  eavesdroppers  and  do  not  expect  large  scale  surveillance 
networks  constructed  using  them  soon.  However,  the  cost  of  such  equipment  will  invari¬ 
ably  come  down  as  it  is  commoditized.  Therefore,  it  is  also  important  to  begin  to  develop 
countermeasures  to  conceal  physical  layer  fingerprints  as  well.  We  believe  that  such  con¬ 
cealment  is  not  technically  difficult  with  hardware  modifications  (e.g.,  Brik  et  al.  [36] 
used  fixed  calibration  errors  to  fingerprint  wireless  cards,  so  inserting  randomized  noise  to 
these  errors  would  mask  the  fingerprints).  However,  doing  so  would  likely  add  to  the  cost 
of  wireless  devices,  so  a  thorough  understanding  of  the  economic  trade-offs  is  crucial  to 
determining  whether  deploying  such  countermeasures  at  scale  is  practical. 
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